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

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Nov 2017 17:51:37 +1100

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.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 28 Nov 2017 09:30:37 -0600

Just chiming in on Martin's last point ...

> mention is probably wise.

I've been talking with the IESG since at least our retreat in May, about
the need for (some value of) us to up-level our discussion so that we're
providing general guidance about privacy, and not just arguing about
privacy on every document where someone notices something (too often,
during IETF Last Call or IESG Evaluation).

If Martin's point is that we don't have an appropriate document to point to
as something like a canonical checklist, it would be great if that changed.
I don't know if a BCP is the right thing to do, but if an RFC providing
guidance already exists, it's not jumping out at me.

Mirja and I hosted Mike Perry from the Tor Project to talk about " Privacy
and Traffic Analysis Resistance for Encrypted Protocols" to TSVAREA at IETF
98, for instance, and that was very helpful, but ISTM that pointing people
to a PowerPoint presentation (Privacy and Traffic Analysis Resistance for
Encrypted Protocols) or MeetEcho recording (
https://www.youtube.com/watch?v=0tvKH_Cnvwg&list=PLC86T-6ZTP5jo6kIuqdyeYYhsKv9sUwG1&index=84,
beginning at about 1:11 from the beginning) may not be the best we could do
...

Thoughts from others?

Spencer, as TSV AD, responsible AD for QUIC, and apparently the Spin Bit AD
...