Subject: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 18 Sep 2019 07:40:18 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-sni-encryption-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** 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)

** 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.

-- 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.

** 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.

** Section 2.1.  Why is parental controls in quotes?  In RFC8404, it is not. 
The quotes could be read as a judgement on the practice.

** 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.

** 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?

** 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?

-- 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”.

** 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).

** Section 3.  Per “Over the past years, there have been multiple proposals to
add an SNI encryption option in TLS.”, can these past proposals be cited so
future readers can learn from them.

** Section 3.4. The existence of designs were alluded to but not cited.  Be
specific with citation.

** Section 3.7.1. The rational for including this discussion about ALPN isn’t
clear as it doesn’t suggest new requirements for SNI encryption.

** Section 4.  I got hung-up on the description of Section 4 describing a
“solution”.  Is Section 4 (and the related subsections) describing an
operational practice or a notional reference architecture?  The text reads one
part “people are doing” and another part “people could do”.

** Section 4.  Per “In the absence of TLS-level SNI encryption, many sites rely
on an "HTTP Co-Tenancy" solution”, this seems like a strong of a statement
about utilization of this architecture explicitly to hide the
hidden.example.com SNI.  Can you provide a citation for a sense penetration.

** Section 4.  Per the bullet “since this is an HTTP-level solution”, I
recommend citing that it fails on the requirement identified in Section 3.7
(instead of enumerating a list of protocols)

** Section 4.  The opening of this section noted that “many sites” rely on the
architecture described in this section. Later, it is noted that “a browser
extension that support[s] HTTP Fronting” is a necessary architecture component.
 Can a few citations be made to the popular extensions.

** Section 4.2.  Per "to reach example   hidden.example.com, use
fake.example.com as a fronting server", shouldn’t this read: “to reach
hidden.example.com, use fake.example.com as a fronting server"?

** Editorial Nits
-- Section 2.  Typo.  s/mutiple/multiple.

-- Section 2.1. Typo.  s/fradulent/fraudulent/

-- Section 3.1.  “Hidden Service” is capitalized in a few places like it is a
proper noun?  Is it meant to be?  If so, define or cite it.

-- Section 3.6. s/the the/

-- Section 4.1. s/tunnelling/tunneling/

-- Section 4.2. s/ferver/server/

-- Section 7.  s/Martin Rex Martin Thomson/Martin Rex, Martin Thomson/

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Sep 2019 16:14:21 -1000

Thanks for the feedback, Roman. Comments in line.

> organization (i.e., looking up to what netblock an IP belongs reveals little)

OK, will try to incorporate your 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?

> explicitly discusses SNI, and of the examples list here, only one comes from
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 quotes could be read as a judgement on the practice.
See answer to Alissa. Removing the quotes.
> speculation and instead simply stating that SNI would be interesting meta-data

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.

> SNI information was available through a variety of other means”, what would

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.

> -- 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...
> 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.
> future readers can learn from them.
We are describing here a series of design proposed in the TLS working 
group over the years. The whole point of the draft is to provide the 
results of the analyses, as an easy to read kind of "threat model", 
without requiring readers to wade through years of archives. If you 
really are interested, you can indeed do just that but I would not 
encourage the approach...
> clear as it doesn’t suggest new requirements for SNI encryption.
Got comments about that already, and updated the text.
> part “people are doing” and another part “people could do”.
Yes, I get that. Our point is to describe this solution as part of 
explaining why we really want a TLS level solution, not just HTTP. Not 
sure that I can change much here.
> hidden.example.com SNI.  Can you provide a citation for a sense penetration.

That's really hard, because it is all cloak and dagger stuff. The one 
well known example is the encrypted messaging application "Signal", that 
was censored in Egypt during the "Arab Spring" events. They were hosted 
by Google, and apparently programmed their app to just connect to 
"https://google.com/", and then use "host: signal.org" in the HTTP 
headers, evading censorship. It is not clear at all to what amount they 
synchronized with Google when doing that. And I don't think that anybody 
ever spoke openly about this.

> (instead of enumerating a list of protocols)
Yes. Already fixed.
>   Can a few citations be made to the popular extensions.

The "Signal" deployment used a service specific app. The trick of using 
https://fronting + Host: hidden is really easy to pull in an app. To do 
that in a browser does indeed require an extension, that's pretty much a 
statement of fact.

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 25 Sep 2019 17:27:53 +0000

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:[email-masked]] On Behalf Of Christian Huitema
> Sent: Wednesday, September 18, 2019 10:14 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
> encryption-05: (with COMMENT)
> 
> > ** 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)
> 
> 

Thanks.

> >
> > ** 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.

> > -- 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.
> >
> > ** 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.

> See answer to Alissa. Removing the quotes.

Thanks.

> > 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.
> 
> 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.

> >
> > ** 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?
> 
> 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.

> believe that all middle-boxes are the spawn of the devil...

Thanks.

> these functions can, however, be realized by other means.

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.

> encourage the approach...

I understand.  It doesn't seem practical to quote mailing list threads.

> sure that I can change much here.

See below.  I think I may have an approach for clarity.

> ever spoke openly about this.

Thanks for the details.  Let me step back and try to restate my concern.  My feedback on the assertion that "many sites rely on an HTTP Co-Tenancy" and the question above about the "browser plugin" all come from my misunderstanding of the purpose of Section 4.   Is it describing a commonly accepted practice already done or a notional reference architecture.  IMO, given the framing of the rest of the document, it should be the latter.

The first paragraph states that "many sites" use this approach which suggested to me an existing best common practice.  However, as you clarified, there is little evidence that can be provided beyond signal.  To me the statement of "many sites" can't be supported.  My thinking is that this could be easy cleared up simply avoiding the discussion about adoption by saying:

OLD:
In the absence of TLS-level SNI encryption, many sites rely on an
"HTTP Co-Tenancy" solution.  The TLS connection is established with
the fronting server, and HTTP requests are then sent over that
connection to the hidden service.

NEW:
In the absence of TLS-level SNI encryption, a site could adopt an "HTTP Co-Tenancy" architecture to protect the SNI information.  In such an architecture, the client establishes a TLS connection with a fronting server, and the HTTP requests are then sent over that connection to the hidden service.

Related to my confusion is also the new text added to Section 1 of -06, "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.

> > (instead of enumerating a list of protocols)

Thanks.

> that in a browser does indeed require an extension, that's pretty much a

Makes sense.  Back to my earlier comment about "many sites", if this text is describing a specific solution/best practice vs. a reference architecture.  If it is the former, then what's actually done needs to be described (i.e., an app-based approach).  If it is the latter, the text is fine.

Roman

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Sep 2019 09:47:00 -1000

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.

>> OK, will try to incorporate your text.

Changes incorporated in first paragraph of section 1.

> 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."

> used by surveillance targets.

I missed the reference to 7258. Will add it in the next version.

> 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.

Fixed in draft 07.

> I understand.  It doesn't seem practical to quote mailing list threads.
There is actually one such quote in the "Acknowledgement" section.
> 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.

> Makes sense.  Back to my earlier comment about "many sites", if this text is describing a specific solution/best practice vs. a reference architecture.  If it is the former, then what's actually do…

Draft 07 added text describing actual deployments.

-- Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Sep 2019 17:41:57 -0700

>    servers that host multiple 'virtual' servers at a single underlying

I think the idea is that you can have a client-side forward proxy or a
server-side reverse proxy, and either of those can be okay, but you don't
want some random unaffiliated thing in the network poking at things.
So, one might have client != server, but (client == middlebox) OR (server
== middlebox), where equality reflects membership in the same
administrative domain.

-Ben

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 26 Sep 2019 16:41:46 +0000

> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2019 8:42 PM
> To: Roman Danyliw <[email-masked]>
> Cc: Christian Huitema <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> > 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
> >
> > > > 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.
> > > > -- 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)
> > >
> > >
> > > > ** 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].”,
> > > >
> > > 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.
> > > "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.
> >
> I think the idea is that you can have a client-side forward proxy or a server-
> side reverse proxy, and either of those can be okay, but you don't want
> some random unaffiliated thing in the network poking at things.
> So, one might have client != server, but (client == middlebox) OR (server ==
> middlebox), where equality reflects membership in the same administrative
> domain.

Understood, but IMO, this is an interpretation of "anticipated use".  Taking a narrow read of RFC3546, I don't see explicit references to proxies, domain boundaries, etc.  The line of thinking I read in this draft is that there are certain anticipated and unanticipated uses of SNI.  If the practice is categorized as unanticipated, then it should be "thwarted" with encrypted SNI (per Section 2.3).  My concern is that with this framing is that we're unnecessarily divining intent from RFC3546 to classify certain practices.  This draft is a commentary on concerns of certain existing practices (whether they were intended or not).

I'm trying to avoid adjudicating whether proxies are middleboxes and what uses were intended.  My proposed text sticks to citable sources by explicitly referencing the purpose of the SNI from RFC3546 and acknowledging that it gets used for other things.

Roman

> -Ben
> 
> > 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.
> >

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 26 Sep 2019 21:38:20 +0000

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".

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Wednesday, September 25, 2019 3:47 PM
> 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.
> 
> >>> same server (i.e., an IP/port doesn’t uniquely identify the service)
> >>>

The text -07 works for me.  Thanks for adding this extra bit.

> >>> 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].”,
> >>>

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

> >>> 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.

> 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?

> >>> ** 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.
> >> 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.
> > 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:
> > pervasive monitoring attacker [RFC7258], for example to identify
> > services used by surveillance targets.
> 

Recommend adding the RFC7258 reference.  As I noted above, the semantics of "probably" vs. "could".  "probably" suggests a confidence to me.

> >>> written, the SNI information was available through a variety of
> >>> other means”, what would those “other means” be?
> >> 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
> >> 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
> >> 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.

> >>> ** Section 3.  Per “Over the past years, there have been multiple
> >>> proposals
> >> to
> >>> add an SNI encryption option in TLS.”, can these past proposals be
> >>> cited so future readers can learn from them.

No problem.

> >>> ** Section 3.4. The existence of designs were alluded to but not
> >>> cited.  Be specific with citation.
> >>>
> >>> ** Section 3.7.1. The rational for including this discussion about
> >>> ALPN isn’t clear as it doesn’t suggest new requirements for SNI
> encryption.

The new intro text is Section 1 explains it better.  Thank you for that preamble.

> >>> ** Section 4.  I got hung-up on the description of Section 4
> >>> describing a “solution”.  Is Section 4 (and the related subsections)
> >>> describing an operational practice or a notional reference
> >>> architecture?  The text reads
> >> one
> >> explaining why we really want a TLS level solution, not just HTTP.
> >> Not sure that I can change much here.
> >>> ** Section 4.  Per “In the absence of TLS-level SNI encryption, many
> >>> sites
> >> rely
> >>> on an "HTTP Co-Tenancy" solution”, this seems like a strong of a
> >>> statement about utilization of this architecture explicitly to hide
> >>> the hidden.example.com SNI.  Can you provide a citation for a sense
> >> penetration.
> >>
> >> well known example is the encrypted messaging application "Signal",
> >> that was censored in Egypt during the "Arab Spring" events. They were
> >> hosted by Google, and apparently programmed their app to just connect
> >> to "https://google.com/", and then use "host: signal.org" in the HTTP
> >> headers, evading censorship. It is not clear at all to what amount
> >> they synchronized with Google when doing that. And I don't think that
> >> anybody ever spoke openly about this.
> > Thanks for the details.  Let me step back and try to restate my concern.  My
> feedback on the assertion that "many sites rely on an HTTP Co-Tenancy" and
> the question above about the "browser plugin" all come from my
> misunderstanding of the purpose of Section 4.   Is it describing a commonly
> accepted practice already done or a notional reference architecture.  IMO,
> given the framing of the rest of the document, it should be the latter.
> >
> > The first paragraph states that "many sites" use this approach which
> suggested to me an existing best common practice.  However, as you
> clarified, there is little evidence that can be provided beyond signal.  To me
> the statement of "many sites" can't be supported.  My thinking is that this
> could be easy cleared up simply avoiding the discussion about adoption by
> saying:
> >
> > OLD:
> > In the absence of TLS-level SNI encryption, a site could adopt an "HTTP Co-
> Tenancy" architecture to protect the SNI information.  In such an
> architecture, the client establishes a TLS connection with a fronting server,
> and the HTTP requests are then sent over that connection to the hidden
> service.
> >
> > Related to my confusion is also the new text added to Section 1 of -06,
> "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.
> 
> >
> >>> ** Section 4.  Per the bullet “since this is an HTTP-level
> >>> solution”, I recommend citing that it fails on the requirement
> >>> identified in Section 3.7 (instead of enumerating a list of
> >>> protocols)
> >> Yes. Already fixed.
> > Thanks.
> >
> >>> ** Section 4.  The opening of this section noted that “many sites”
> >>> rely on
> >> the
> >>> architecture described in this section. Later, it is noted that “a
> >>> browser extension that support[s] HTTP Fronting” is a necessary
> >>> architecture
> >> component.
> >> The "Signal" deployment used a service specific app. The trick of
> >> using https://fronting + Host: hidden is really easy to pull in an
> >> app. To do that in a browser does indeed require an extension, that's
> >> pretty much a statement of fact.
> > Makes sense.  Back to my earlier comment about "many sites", if this text is
> describing a specific solution/best practice vs. a reference architecture.  If it is
> the former, then what's actually done needs to be described (i.e., an app-
> based approach).  If it is the latter, the text is fine.
> 

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

** 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.

Thanks,
Roman

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Sep 2019 12:53:25 -1000

> 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…

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."

> 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.

> ...

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.

> s/including censorship and pervasive surveillance/including pervasive surveillance/

OK.

> ...
> ...

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.

>> ...

> ** 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 encryp…

OK, will try make clear that this is not an endorsement or a proposal.

-- Christian Huitema