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

Christian Huitema <huitema@huitema.net> Wed, 25 September 2019 19:51 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A16012022C for <tls@ietfa.amsl.com>; Wed, 25 Sep 2019 12:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhZylRFhRWnt for <tls@ietfa.amsl.com>; Wed, 25 Sep 2019 12:51:44 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298AD12081B for <tls@ietf.org>; Wed, 25 Sep 2019 12:51:40 -0700 (PDT)
Received: from xse61.mail2web.com ([66.113.196.61] helo=xse.mail2web.com) by mx62.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iDDK5-0001gy-Nv for tls@ietf.org; Wed, 25 Sep 2019 21:51:38 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46dpVJ2lK0z99nR for <tls@ietf.org>; Wed, 25 Sep 2019 12:47:04 -0700 (PDT)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iDDFg-0001ir-8T for tls@ietf.org; Wed, 25 Sep 2019 12:47:04 -0700
Received: (qmail 26458 invoked from network); 25 Sep 2019 19:47:03 -0000
Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 25 Sep 2019 19:47:03 -0000
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-tls-sni-encryption@ietf.org" <draft-ietf-tls-sni-encryption@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
References: <156881761812.4630.11745895149419124830.idtracker@ietfa.amsl.com> <c504a433-cc5b-df00-15c2-fcaf3116798c@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <81e39835-82e7-03c7-feaf-33980629986c@huitema.net>
Date: Wed, 25 Sep 2019 09:47:00 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0
MIME-Version: 1.0
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.61
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.61/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.61/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4b6d91VsVFLy9b/ezIo+MI0gyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+e8hb1lxHddBtWcfnl7xl+wmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdGd9U9Oojh2QY0MMPWjRsTVhMmX9VvKuj6psZloQqgYBwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPmz5tsQu9R3vp aAMkTA7gTKoJngF7rJQgeWTjF5V/EGvRS0YlJIHQC5c5TWhTTZLiBhO8u0ag4+i9kLOW9cRnakfI ez8zXIJQjuq8u309eJ898YhI0T+E7bfVzyzh3DkvygyEZ9MYp5iiF2omUcFCWyHS4i+qiRR1gXOs rnQ+IMV0JwCelAgxI3HE4I5TUXrjZmbwg5RQyvb6891H3AUBP1Wm4lF87PQVhRsTMmF5z6gFZuM7 jUXIESohoO51xWmU8b6nvhh4t4ghrEakeaI2PBYJsxB0mSXXZreDXDy7oYnH86LodOZj79xdSjzK bqR5XHk0qi1hkw/hDGKWkPVYlXF3BhZxGgZFOwvGprxNGaa6/2rAztFeklLxGNN3KHaPkMjB65Ki hPq1I9TXHnOlSkg/OIORZDl9o+TmclcfPTQwNGP0PwcsocAqk8Y/wQ+e4HndwcgUdq9CmjcVQOst ghA=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nx3JwrntSOWda0G2J69zIGjPQEg>
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2019 19:51:48 -0000

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


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

Was rewritten in new section 2.1 as "Filtering or censorship of specific
services for a variety of reasons."

>>> ** 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.
>> See answer to Alissa. Removing the quotes.
> Thanks.
>
>>> ** 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.

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

>>> ** 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.
>> 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...
> I understand.  It doesn't seem practical to quote mailing list threads.
There is actually one such quote in the "Acknowledgement" section.
>
>>> ** 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.
>> Got comments about that already, and updated the text.
>>> ** 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”.
>> 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.
> See below.  I think I may have an approach for clarity.
>
>>> ** 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.
>>
>> 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.
> 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.


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

Draft 07 added text describing actual deployments.

-- Christian Huitema