[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
From: Christian Huitema <huitema () huitema ! net>
Date: 2019-09-26 22:53:25
Message-ID: 2efdf56d-2846-a08e-2b2d-aa0703281b18 () huitema ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 9/26/2019 11:38 AM, Roman Danyliw wrote:
> Hi Christian!
>
> Thanks for all of the updates. I have a remaining items are described inline.
>
> To bring up a new item, there was new text introduced in -06 of Section 5 to which \
> I strongly object. Specifically:
> "Replacing clear text SNI transmission by an encrypted variant will
> also thwart MITM interferences that are sometimes described as
> legitimate. As explained in Section 2.3, alternative solutions will
> have to be developed."
>
> I read this paragraph as addressing the operational practices outlined in Section \
> 2.1. I think it is inappropriate to refer to some of these operational practices \
> as being "sometimes described as legitimate".
Anything performed by MITM is by definition controversial. But I get
your point. How about
"Replacing clear text SNI transmission by an encrypted variant will break or reduce \
the efficacy of the operational practices and techniques implemented in middle-boxes \
as described in Section 2.1. As explained in Section 2.3, alternative solutions will
have to be developed."
>
> > -----Original Message-----
> > From: Christian Huitema [mailto:huitema@huitema.net]
> > Sent: Wednesday, September 25, 2019 3:47 PM
> > To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
> > Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org; tls@ietf.org
> > Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
> > encryption-05: (with COMMENT)
> >
> > Hello Roman,
> >
> > A lot of the fixes that you suggested are incorporated in the draft-07 that was
> > just released. I think the last version addresses your concerns, but you may
> > of course want to verify.
> >
> > On 9/25/2019 7:27 AM, Roman Danyliw wrote:
> > > Hi Christian!
> > >
> > > Thanks for the detailed responses and the helpful background. Below are a
> > number of proposed text block replacements to clarify my intent (instead of
> > more questions).
> > > Roman
> > >
> > > > -----Original Message-----
> > > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Christian
> > > > Huitema
> > > > Sent: Wednesday, September 18, 2019 10:14 PM
> > > > To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
> > > > Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org;
> > > > tls@ietf.org
> > > > Subject: Re: [TLS] Roman Danyliw's No Objection on
> > > > draft-ietf-tls-sni-
> > > > encryption-05: (with COMMENT)
> > > >
> > > > Thanks for the feedback, Roman. Comments in line.
> > > >
> > > > On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
> > > > > ** Section 1. Per "More and more services are colocated on
> > > > > multiplexed servers, loosening the relation between IP address and
> > > > > web service", completely agree. IMO, unpacking "multiplexed
> > > > > servers" is worthwhile to explain the subsequent text because it
> > > > > motivates the loss of visibility due to encryption with network only
> > monitoring.
> > > > "Multiplex' happens at two levels:
> > > > > -- co-tenants (e.g., virtual hosting) – multiple services on the
> > > > > same server (i.e., an IP/port doesn't uniquely identify the service)
> > > > >
> > > > > -- cloud/cdn – a given platform hosts the services/servers of a lot
> > > > > of organization (i.e., looking up to what netblock an IP belongs
> > > > > reveals little)
> > > > OK, will try to incorporate your text.
> > > Thanks.
> > Changes incorporated in first paragraph of section 1.
> The text -07 works for me. Thanks for adding this extra bit.
>
> > > > > ** Section 2.1. Per "The SNI was defined to facilitate management
> > > > > of servers, though the developers of middleboxes soon found out that
> > > > > they could take advantage of the information. Many examples of such
> > > > > usage are reviewed in [RFC8404].",
> > > > >
> > > > > -- Can't middleboxes also help facilitate the management of servers?
> > > > > This text seems to take a particular view on middleboxes which
> > > > > doesn't
> > > > seem appropriate.
> > > >
> > > > It is pretty clear that the load balancer in front of a server farm
> > > > will need access to the service ID, and must be able to retrieve the
> > decrypted SNI.
> > > > There may be other examples, such as DoS mitigation boxes. The
> > > > "unanticipated usage" comes typically from middle-boxes that are not
> > > > in the same management domain as either the client or the server. Is
> > > > there an established way to designate those?
> > > I'm not sure I understand the original of the requirement that the client
> > and server being in the same management domain.
> > > RFC3546's definition of SNI opens with:
> > > [TLS] does not provide a mechanism for a client to tell a server the
> > > name of the server it is contacting. It may be desirable for clients
> > > to provide this information to facilitate secure connections to
> > > servers that host multiple 'virtual' servers at a single underlying
> > > network address.
> > >
> > > It seems to me that if we are trying to channel original intent, then only the
> > virtual server use case applies. I'd propose:
> > > OLD
> > > The SNI was defined to facilitate management of servers, though the
> > developers of middleboxes soon found out that they could take advantage
> > of the information. Many examples of such usage are reviewed in
> > [RFC8404].
> > > NEW
> > > The SNI was defined to facilitate secure connections to servers that host
> > multiple 'virtual' servers at a single underlying network address [RFC3546].
> > However, addition management and security practices emerged making use
> > of this information. Examples of such usage are reviewed in [RFC8404].
> > > This language would let you distinguish all of the middle box behaviors
> > done by operators and enterprises from a possible [RFC7258] attacker.
> As I noted in my reply to Ben, I don't follow the current language for \
> anticipated/unanticipated.
> https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y
>
> > > > > -- RFC8404 describes a number of middlebox practices, but only
> > > > > Section
> > > > > 6.2 explicitly discusses SNI, and of the examples list here, only
> > > > > one comes from RFC8404.
> > > > A few of the examples also come in the "deep packet inspection"
> > > > sections of 8404. But rather than going in a long discussion, I would
> > > > rather rewrite the sentence as: Many examples of such usage are
> > > > reviewed in [@?RFC8404], other examples came out during discussions of
> > this draft.
> The -07 text works for me. Thanks.
>
> > > > > ** Section 2.1. The "monitoring and identification of specific sites"
> > > > > isn't symmetric to the other examples – it is rather generic. The
> > > > > other examples, identify a what/who (e.g., ISP, firewall) + action
> > > > > (e.g.,
> > > > block, filter).
> > > > > Also, to implement most of the other example, "monitoring and
> > > > > identification of specific sites" needs to be done.
> > > I still think this needs to be cleaned up in some way. IMO, I'd drop it.
> > Was rewritten in new section 2.1 as "Filtering or censorship of specific
> > services for a variety of reasons."
> I'm still struggling with the specificity here and the overlap. Dropping the \
> censorship and it reads "filtering of specific services for a variety of reasons". \
> That's exactly what bullet 2 (content filtering by operators) and bullet 3 \
> (enterprise firewalls for NSFW)
> What's unique about this bullet -- is it who is doing this filter/censorship? where \
> it is happening? What tech is being used?
For example, arbitrary filtering of web sites competing with other
services preferred by the network provider. Some filtering and
censorship is more controversial than others. But I don't think that
listing every controversial usage would be appropriate. I would rather
keep the somewhat vague phrasing than try to have a debate about which
practice is controversial and which is not.
> ...
> > > > > ** Section 2.1. Per "The SNI is probably also included in the
> > > > > general collection of metadata by pervasive surveillance actors", I
> > > > > recommend against speculation and instead simply stating that SNI
> > > > > would be interesting meta-data for a RFC7258 attacker.
> > > > Yes, Mirja made a similar comment. Proposed replacement:
> > > >
> > > > The SNI is probably also included in the general collection of
> > > > metadata by pervasive surveillance actors, for example to identify
> > > > services used by surveillance targets.
> > > IMO, explicitly linking it to the draft would help.
> > >
> > > OLD:
> > > The SNI is probably also included in the general collection of
> > > metadata by pervasive surveillance actors, for example to identify
> > > services used by surveillance targets.
> > >
> > > NEW:
> > > The SNI could be included in the general collection of metadata by
> > > pervasive monitoring attacker [RFC7258], for example to identify
> > > services used by surveillance targets.
> > I missed the reference to 7258. Will add it in the next version.
> Recommend adding the RFC7258 reference. As I noted above, the semantics of \
> "probably" vs. "could". "probably" suggests a confidence to me.
Yes, there is some confidence, based on the Snowden revelation of
systems like Quantum Insert, comments like "recording the whole
haystack", or the Korean regulation explicitly targeting the SNI field.
It is more probable than not that SNI data is being recorded, and I
think that "probably" is just fine.
>
> > > > > ** Section 2.2. Per "One reason may be that, when these RFCs were
> > > > > written, the SNI information was available through a variety of
> > > > > other means", what would those "other means" be?
> > > > The list includes at a minimum:
> > > >
> > > > Clear text exchanges amenable to deep packet inspection (DPI), server
> > > > certificates send in clear text during TLS/SSL exchanges, DNS names
> > > > of servers in clear text DNS queries, and server specific IP
> > > > addresses in packet headers.
> > > >
> > > > I guess I could write that all, but it makes the text a bit
> > > > redundant, since the following paragraphs do discuss server
> > > > certificates, DNS names and IP addresses.
> > > I understand. I didn't read it that way. My recommendation isn't to
> > describe the "other means" (as it is described below), but to be clear on the
> > obvious, what is the SNI information.
> > > OLD:
> > > One reason may be that, when these RFCs were written, the SNI
> > > information was available through a variety of other means.
> > >
> > > NEW:
> > > One reason may be that when the RFCs were written, the name of the
> > server the being contacted by the client (i.e., the SNI) was evident through
> > other means.
> The new text in -07 reads more clearly to me. Thanks for this change.
>
> > > > > ** Section 2.3. Per "Deploying SNI encryption will help thwarting
> > > > > most of
> > > > the
> > > > > ‘unanticipated' SNI usages described in Section 2.1, including
> > > > > censorship
> > > > and
> > > > > pervasive surveillance.":
> > > > >
> > > > > -- Why the quotes around "unanticipated" SNI usage?
> > > > Removing the quotes. Otherwise, you will be convinced that the
> > > > authors believe that all middle-boxes are the spawn of the devil...
> > > Thanks.
> > >
> > > > > -- One person's censorship is another person's threat mitigation,
> > > > > policy enforcement for a network they own, or parental controls (per
> > > > > the list in Section 2.1) – recommend being more precise on the order
> > > > > of "Deploying
> > > > SNI
> > > > > encryption will {break | reduce the efficacy of } the operational
> > > > > practices
> > > > and
> > > > > techniques used in middleboxes described in Section 2.1".
> > > > OK. I will try to make the text just stick to the facts:
> > > >
> > > > Deploying SNI encryption thwarts most of the unanticipated SNI usages
> > > > described in (#snileak). It reduces the efficacy of the operational
> > > > practices and techniques implement in middle-boxes. Most of these
> > > > functions can, however, be realized by other means.
> Thanks for this.
>
> > > Works for me. However, I'd drop "Most of these functions can, however,
> > be realized by other means" because this opens the debate on how exactly,
> > etc.
> I still recommend dropping the "other means" text because that opens debate.
>
> > > > > ** Section 2.3. Per "It will also thwart functions that are
> > > > > sometimes described as legitimate", what functions are those? I'd
> > > > > recommend
> > > > eliminating
> > > > > this sentence as it reads like a value judgement on existing
> > > > > practices (which doesn't seem germane for discussing requirements).
> Now that censorship got added to the list in Section 2.1, you likely want to:
>
> s/including censorship and pervasive surveillance/including pervasive surveillance/
>
> Otherwise, LGTM. Thanks.
OK.
> ...
> ...
> > "This document does not present the design of a solution, but provides
> > guidelines for evaluating proposed solutions." However, the current text in
> > Section 4 is explicitly states it is providing a solution. The sub-section of
> > Section 4.x assume the solution in Section 4.0 and describe the follow-on
> > work. Section 2 - 3 do lay out the means for evaluation nicely. Perhaps,
> > something on the order of:
> > > OLD:
> > > This document does not present the design of a solution, but provides
> > guidelines for evaluating proposed solutions.
> > > NEW:
> > > This provides guidelines on evaluating solution and proposes an
> > architecture to mitigate the threats created by an unencrypted SNI using
> > existing approaches.
> >
> >
> > I added the reference to a paper by Fified et al. that describes the "domain
> > fronting" solution and some of its deployments.
Note that the intent is not to recommend the domain fronting solution.
That solution, and the HTTPS tunnel solution, are examined as example of
proposed solutions that meet some of the requirement but not all. But I
understand that you perceived the text as some kind of endorsement.
> > ...
> > Draft 07 added text describing actual deployments.
> The use of the [domfront] citation works for me and addresses my concerns. Two \
> nits:
> ** I'd recommend using the URL to the paper from conference site itself: \
> https://petsymposium.org/2015/papers/03_Fifield.pdf
OK.
>
> ** I'd also recommend adding a sentence to the last paragraph of Section 1, "This \
> document does not present the design ...", to foreshadow that you'll discuss an \
> alternative approach even if encrypted SNI isn't realized yet.
OK, will try make clear that this is not an endorsement or a proposal.
-- Christian Huitema
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/26/2019 11:38 AM, Roman Danyliw
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">Hi Christian!
Thanks for all of the updates. I have a remaining items are described inline.
To bring up a new item, there was new text introduced in -06 of Section 5 to which I \
strongly object. Specifically:
"Replacing clear text SNI transmission by an encrypted variant will
also thwart MITM interferences that are sometimes described as
legitimate. As explained in Section 2.3, alternative solutions will
have to be developed."
I read this paragraph as addressing the operational practices outlined in Section \
2.1. I think it is inappropriate to refer to some of these operational practices as \
being "sometimes described as legitimate".</pre> </blockquote>
<p>Anything performed by MITM is by definition controversial. But I
get your point. How about <br>
</p>
<pre>"Replacing clear text SNI transmission by an encrypted variant will break or \
reduce the efficacy of the operational practices and techniques implemented in \
middle-boxes as described in Section 2.1. As explained in Section 2.3, alternative \
solutions will have to be developed."</pre>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-----Original Message-----
From: Christian Huitema [<a class="moz-txt-link-freetext" \
href="mailto:huitema@huitema.net">mailto:huitema@huitema.net</a>]
Sent: Wednesday, September 25, 2019 3:47 PM
To: Roman Danyliw <a class="moz-txt-link-rfc2396E" \
href="mailto:rdd@cert.org"><rdd@cert.org></a>; The IESG <a \
class="moz-txt-link-rfc2396E" \
href="mailto:iesg@ietf.org"><iesg@ietf.org></a>
Cc: <a class="moz-txt-link-abbreviated" \
href="mailto:draft-ietf-tls-sni-encryption@ietf.org">draft-ietf-tls-sni-encryption@ietf.org</a>; \
<a class="moz-txt-link-abbreviated" \
href="mailto:tls-chairs@ietf.org">tls-chairs@ietf.org</a>; <a \
class="moz-txt-link-abbreviated" \
href="mailto:tls@ietf.org">tls@ietf.org</a>
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
encryption-05: (with COMMENT)
Hello Roman,
A lot of the fixes that you suggested are incorporated in the draft-07 that was
just released. I think the last version addresses your concerns, but you may
of course want to verify.
On 9/25/2019 7:27 AM, Roman Danyliw wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Christian!
Thanks for the detailed responses and the helpful background. Below are a
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">number of proposed text block replacements \
to clarify my intent (instead of more questions).
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Roman
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-----Original Message-----
From: iesg [<a class="moz-txt-link-freetext" \
href="mailto:iesg-bounces@ietf.org">mailto:iesg-bounces@ietf.org</a>] On Behalf Of \
Christian Huitema
Sent: Wednesday, September 18, 2019 10:14 PM
To: Roman Danyliw <a class="moz-txt-link-rfc2396E" \
href="mailto:rdd@cert.org"><rdd@cert.org></a>; The IESG <a \
class="moz-txt-link-rfc2396E" \
href="mailto:iesg@ietf.org"><iesg@ietf.org></a>
Cc: <a class="moz-txt-link-abbreviated" \
href="mailto:draft-ietf-tls-sni-encryption@ietf.org">draft-ietf-tls-sni-encryption@ietf.org</a>; \
<a class="moz-txt-link-abbreviated" \
href="mailto:tls-chairs@ietf.org">tls-chairs@ietf.org</a>; <a \
class="moz-txt-link-abbreviated" \
href="mailto:tls@ietf.org">tls@ietf.org</a>
Subject: Re: [TLS] Roman Danyliw's No Objection on
draft-ietf-tls-sni-
encryption-05: (with COMMENT)
Thanks for the feedback, Roman. Comments in line.
On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 1. Per "More and more \
services are colocated on multiplexed servers, loosening the relation between IP \
address and web service", completely agree. IMO, unpacking "multiplexed
servers" is worthwhile to explain the subsequent text because it
motivates the loss of visibility due to encryption with network only
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">monitoring.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">"Multiplex' happens at two levels:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-- co-tenants (e.g., virtual \
hosting) – multiple services on the same server (i.e., an IP/port doesn't uniquely \
identify the service)
-- cloud/cdn – a given platform hosts the services/servers of a lot
of organization (i.e., looking up to what netblock an IP belongs
reveals little)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
OK, will try to incorporate your text.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Thanks.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Changes incorporated in first paragraph of section 1.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The text -07 works for me. Thanks for adding this extra bit.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 2.1. Per "The SNI was \
defined to facilitate management of servers, though the developers of middleboxes \
soon found out that they could take advantage of the information. Many examples of \
such usage are reviewed in [RFC8404].",
-- Can't middleboxes also help facilitate the management of servers?
This text seems to take a particular view on middleboxes which
doesn't
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">seem appropriate.
It is pretty clear that the load balancer in front of a server farm
will need access to the service ID, and must be able to retrieve the
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">decrypted SNI.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">There may be other examples, such as \
DoS mitigation boxes. The "unanticipated usage" comes typically from middle-boxes \
that are not in the same management domain as either the client or the server. Is
there an established way to designate those?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I'm not sure I understand the original \
of the requirement that the client </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">and server being in the same management \
domain. </pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
RFC3546's definition of SNI opens with:
[TLS] does not provide a mechanism for a client to tell a server the
name of the server it is contacting. It may be desirable for clients
to provide this information to facilitate secure connections to
servers that host multiple 'virtual' servers at a single underlying
network address.
It seems to me that if we are trying to channel original intent, then only the
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">virtual server use case applies. I'd \
propose: </pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
OLD
The SNI was defined to facilitate management of servers, though the
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">developers of middleboxes soon found out \
that they could take advantage of the information. Many examples of such usage are \
reviewed in [RFC8404].
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
NEW
The SNI was defined to facilitate secure connections to servers that host
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">multiple 'virtual' servers at a single \
underlying network address [RFC3546]. However, addition management and security \
practices emerged making use of this information. Examples of such usage are \
reviewed in [RFC8404]. </pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
This language would let you distinguish all of the middle box behaviors
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">done by operators and enterprises from a \
possible [RFC7258] attacker. </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
As I noted in my reply to Ben, I don't follow the current language for \
anticipated/unanticipated.
<a class="moz-txt-link-freetext" \
href="https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y">https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-- RFC8404 describes a number of \
middlebox practices, but only Section
6.2 explicitly discusses SNI, and of the examples list here, only
one comes from RFC8404.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">A few of the examples also come in the \
"deep packet inspection" sections of 8404. But rather than going in a long \
discussion, I would rather rewrite the sentence as: Many examples of such usage are
reviewed in [@?RFC8404], other examples came out during discussions of
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">this draft.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The -07 text works for me. Thanks.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 2.1. The "monitoring and \
identification of specific sites" isn't symmetric to the other examples – it is \
rather generic. The other examples, identify a what/who (e.g., ISP, firewall) + \
action (e.g.,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">block, filter).
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Also, to implement most of the other \
example, "monitoring and identification of specific sites" needs to be done.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">I still think this needs to be cleaned \
up in some way. IMO, I'd drop it. </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Was rewritten in new section 2.1 as "Filtering or censorship of specific
services for a variety of reasons."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'm still struggling with the specificity here and the overlap. Dropping the \
censorship and it reads "filtering of specific services for a variety of reasons". \
That's exactly what bullet 2 (content filtering by operators) and bullet 3 \
(enterprise firewalls for NSFW)
What's unique about this bullet -- is it who is doing this filter/censorship? where \
it is happening? What tech is being used?</pre> </blockquote>
<p>For example, arbitrary filtering of web sites competing with
other services preferred by the network provider. Some filtering
and censorship is more controversial than others. But I don't
think that listing every controversial usage would be appropriate.
I would rather keep the somewhat vague phrasing than try to have a
debate about which practice is controversial and which is not.<br>
</p>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">
....
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 2.1. Per "The SNI is \
probably also included in the general collection of metadata by pervasive \
surveillance actors", I recommend against speculation and instead simply stating that \
SNI would be interesting meta-data for a RFC7258 attacker.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Yes, Mirja made a similar comment. \
Proposed replacement:
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify
services used by surveillance targets.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">IMO, explicitly linking it to the draft \
would help.
OLD:
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify
services used by surveillance targets.
NEW:
The SNI could be included in the general collection of metadata by
pervasive monitoring attacker [RFC7258], for example to identify
services used by surveillance targets.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I missed the reference to 7258. Will add it in the next version.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Recommend adding the RFC7258 reference. As I noted above, the semantics of \
"probably" vs. "could". "probably" suggests a confidence to me.</pre> </blockquote>
<p>Yes, there is some confidence, based on the Snowden revelation of
systems like Quantum Insert, comments like "recording the whole
haystack", or the Korean regulation explicitly targeting the SNI
field. It is more probable than not that SNI data is being
recorded, and I think that "probably" is just fine.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 2.2. Per "One reason may \
be that, when these RFCs were written, the SNI information was available through a \
variety of other means", what would those "other means" be?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">The list includes at a minimum:
Clear text exchanges amenable to deep packet inspection (DPI), server
certificates send in clear text during TLS/SSL exchanges, DNS names
of servers in clear text DNS queries, and server specific IP
addresses in packet headers.
I guess I could write that all, but it makes the text a bit
redundant, since the following paragraphs do discuss server
certificates, DNS names and IP addresses.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I understand. I didn't read it that \
way. My recommendation isn't to </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">describe the "other means" (as it is \
described below), but to be clear on the obvious, what is the SNI information.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
OLD:
One reason may be that, when these RFCs were written, the SNI
information was available through a variety of other means.
NEW:
One reason may be that when the RFCs were written, the name of the
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">server the being contacted by the client \
(i.e., the SNI) was evident through other means.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The new text in -07 reads more clearly to me. Thanks for this change.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 2.3. Per "Deploying SNI \
encryption will help thwarting most of
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">the
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">‘unanticipated' SNI usages \
described in Section 2.1, including censorship
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">and
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">pervasive surveillance.":
-- Why the quotes around "unanticipated" SNI usage?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Removing the quotes. Otherwise, you \
will be convinced that the authors believe that all middle-boxes are the spawn of the \
devil... </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Thanks.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-- One person's censorship is \
another person's threat mitigation, policy enforcement for a network they own, or \
parental controls (per the list in Section 2.1) – recommend being more precise on \
the order of "Deploying
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">SNI
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">encryption will {break | reduce the \
efficacy of } the operational practices
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">and
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">techniques used in middleboxes \
described in Section 2.1". </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">OK. I will try to make the text just \
stick to the facts:
Deploying SNI encryption thwarts most of the unanticipated SNI usages
described in (#snileak). It reduces the efficacy of the operational
practices and techniques implement in middle-boxes. Most of these
functions can, however, be realized by other means.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Thanks for this.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Works for me. However, I'd drop "Most \
of these functions can, however, </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">be realized by other means" because this \
opens the debate on how exactly, etc.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I still recommend dropping the "other means" text because that opens debate.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">** Section 2.3. Per "It will also \
thwart functions that are sometimes described as legitimate", what functions are \
those? I'd recommend
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">eliminating
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">this sentence as it reads like a \
value judgement on existing practices (which doesn't seem germane for discussing \
requirements). </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Now that censorship got added to the list in Section 2.1, you likely want to:
s/including censorship and pervasive surveillance/including pervasive surveillance/
Otherwise, LGTM. Thanks.</pre>
</blockquote>
<p>OK.<br>
</p>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">
....
</pre>
...
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">"This document does not present the design \
of a solution, but provides guidelines for evaluating proposed solutions." However, \
the current text in Section 4 is explicitly states it is providing a solution. The \
sub-section of Section 4.x assume the solution in Section 4.0 and describe the \
follow-on work. Section 2 - 3 do lay out the means for evaluation nicely. Perhaps,
something on the order of:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
OLD:
This document does not present the design of a solution, but provides
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">guidelines for evaluating proposed \
solutions. </pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
NEW:
This provides guidelines on evaluating solution and proposes an
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">architecture to mitigate the threats \
created by an unencrypted SNI using existing approaches.
I added the reference to a paper by Fified et al. that describes the "domain
fronting" solution and some of its deployments.</pre>
</blockquote>
</blockquote>
<p><br>
</p>
<p>Note that the intent is not to recommend the domain fronting
solution. That solution, and the HTTPS tunnel solution, are
examined as example of proposed solutions that meet some of the
requirement but not all. But I understand that you perceived the
text as some kind of endorsement.<br>
</p>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
....</pre>
</blockquote>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Draft 07 added text describing actual deployments.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The use of the [domfront] citation works for me and addresses my concerns. Two nits:
** I'd recommend using the URL to the paper from conference site itself: <a \
class="moz-txt-link-freetext" \
href="https://petsymposium.org/2015/papers/03_Fifield.pdf">https://petsymposium.org/2015/papers/03_Fifield.pdf</a></pre>
</blockquote>
OK.<br>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">
** I'd also recommend adding a sentence to the last paragraph of Section 1, "This \
document does not present the design ...", to foreshadow that you'll discuss an \
alternative approach even if encrypted SNI isn't realized yet.</pre> </blockquote>
<p>OK, will try make clear that this is not an endorsement or a
proposal.</p>
<p>-- Christian Huitema<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon">
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic