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

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:
> 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 <ietf-announce-bounces@ietf.org> On Behalf Of The IESG
> Sent: Monday, August 19, 2019 9:59 AM
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: draft-ietf-tls-sni-encryption@ietf.org; tls@ietf.org; tls-chairs@ietf.org
> 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 ietf@ietf..org mailing lists by 2019-09-02. Exceptionally, comments may be sent to iesg@ietf.org 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
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 