Subject: RE: Last Call: <draft-ietf-tls-sni-encryption-05.txt> (Issues and Requirements for SNI Encryption in TLS) to Informational RFC

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Aug 2019 19:26:29 +0000

Section 3.6:
   The downside is the the
   client will not verify the identity of the fronting service with
   risks discussed in , but solutions will have to mitigate this risks.
   Overall, end-to-end TLS to the protected service is preferable.

"the the" => "that the"
"discussed in ," presumably was intended to include a reference to... something.
"this risks" => "these risks"

Section 3.7:
   These applications
   too will benefit of SNI encryption.  HTTP only methods like those
   described in Section 4.1 would not apply there.  In fact, even for
   the HTTPS case, the HTTPS tunneling service described in Section 4.1
   is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly
   with the multiple streams feature of HTTP 2.0 [RFC7540].  This points
   to the need of an application-agnostic solution, that would be
   implemented fully in the TLS layer.

"benefit to" => "benefit from"
"HTTP only" => "HTTP-only"
"HTTP 2.0" => "HTTP/2"
"solution, that would" => "solution which can"

Section 4.2
   This requires a
   controlled way to indicate which fronting ferver is acceptable by the
   hidden service.

"ferver" => "server"

   We can observe that content distribution network have a similar
   requirement.  They need to convince the client that "www.example.com"
   can be accessed through the seemingly unrelated "cdn-node-
   xyz.example.net".  Most CDNs have deployed DNS-based solutions to
   this problem.

It might be worth mentioning that when a CDN deploys a "DNS-based solution to this problem," it also holds the authoritative certificate of the origin.  There is simultaneously verification of a relationship between the origin and the CDN (because the certificate can be verified) and a risk that the CDN can spoof the content from the origin.

Section 5

Having described in 2.3 that encrypting SNI will simultaneously thwart invasions of the TLS exchange whose purpose is to improve some forms of security, I suspect this is worth a mention in the Security Considerations as well.

Section 7

"Martin Rex Martin Thomson and" => "Martin Rex, Martin Thomson, and"

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of The IESG
Sent: Monday, August 19, 2019 9:59 AM
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Last Call: <draft-ietf-tls-sni-encryption-05.txt> (Issues and Requirements for SNI Encryption in TLS) to Informational RFC

The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Issues and Requirements for SNI Encryption in TLS'
  <draft-ietf-tls-sni-encryption-05.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2019-09-02. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   This draft describes the general problem of encrypting the Server
   Name Identification (SNI) TLS parameter.  The proposed solutions hide
   a Hidden Service behind a fronting service, only disclosing the SNI
   of the fronting service to external observers.  The draft lists known
   attacks against SNI encryption, discusses the current "co-tenancy
   fronting" solution, and presents requirements for future TLS layer
   solutions.

   In practice, it may well be that no solution can meet every
   requirement, and that practical solutions will have to make some
   compromises.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 24 Aug 2019 15:06:58 -0500

Hi Mike,

Thanks for this.  The first two at least are already fixed in the editor's
copy, and I'll make sure that the rest get addressed before publication.

-Ben

On Wed, Aug 21, 2019 at 07:26:29PM +0000, Mike Bishop wrote:
> It might be worth mentioning that when a CDN deploys a "DNS-based solution to this problem," it also holds the authoritative certificate of the origin..  There is simultaneously verification of a relationship between the origin and the CDN (because the certificate can be verified) and a risk that the CDN can spoof the content from the origin.
> 
> Section 5
> 
> Having described in 2.3 that encrypting SNI will simultaneously thwart invasions of the TLS exchange whose purpose is to improve some forms of security, I suspect this is worth a mention in the Security Considerations as well..
> 
> Section 7
> 
> The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf..org mailing lists by 2019-09-02. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>