draft-mm-wg-effect-encrypt-13 Sections 6.2-6.4

[Martin Thomson <[e-mail]>]

I haven't time at the moment to go through this document in detail.
But I did notice a few obvious errors in the mentioned sections.

6.2

SNI encryption has been adopted by the TLS WG, but that doesn't mean
that all future versions of TLS will include the capability - or even
be able to use it - as the text implies.  Encrypting SNI calls for
some hard trade-offs that likely mean that encryption won't be
universally deployed.  I do appreciate the effort to forewarn about
this, but it misses the point somewhat.

The point here is that SNI is being used as a proxy for identification
of content.  That it is a poor proxy is widely acknowledged (though
not in the draft), but it has been more or less accepted as adequate
for some applications of content-based discrimination.

Let's say that we accept that as implicit - rather than a cleaner
explicit statement - and continue to focus on identification of
content via SNI.  In that case, RFC 7540 defined something that should
be more of a concern: connection coalescing.  That feature is also
widely implemented in browsers.  The ORIGIN frame
(draft-ietf-httpbis-origin-frame) makes this stronger by potentially
taking DNS out of the loop.  Add the likely-to-be-adopted
draft-bishop-httpbis-http2-additional-certs and things far more
challenging for snooping than merely encrypting SNI.

This is misleading:

   It should be noted that
   HTTP/2 introduces the Alt-SVC method for upgrading the connection
   from HTTP/1 to either unencrypted or encrypted HTTP/2.  If the
   initial HTTP/1 request is unencrypted, the destination alternate
   service name can be identified before the communication is
   potentially upgraded to encrypted HTTP/2 transport.

RFC 8164 defines the use of Alt-Svc [check capitalization] for
opportunistically upgrading to an encrypted (and authenticated!)
transport.  The claim here that the service name can be identified is
perhaps correct, but also unnecessary, since the alternative is
contacted using the SNI of the original (as defined in RFC 7838).


6.3

As I mentioned in a previous review, ALPN is not encrypted in TLS 1.3.
The correct statement would be that ALPN options are available to the
network (just like SNI), but the selection by the server is not.  I'm
still not sure what use cases this datum drives though.

6.4

This mentions nothing of padding.  Padding is available in HTTP/2 and
TLS 1.3, plus many other protocols.  It at least deserves some
recognition, even if it isn't widely deployed (outside of some
relatively specialized uses, that is).  There's a whole RFC on traffic
analysis and countermeasures missing from our dialogue here, but a
mention is probably wise.