Code change:
3.2. <del> Connection establishment requires cleartext packets and is using a TLS handshake on stream 0.  Therefore it is detectable using heuristics similar to those used to detect TLS over TCP. 0-RTT connection may additional also send data packets, right after the Client Initial with the TLS client hello.  These data may be reordered in the network, therefore it may be possible that 0-RTT Protected data packets are seen before the Client Initial packet. </del> <ins> Connection establishment uses Initial, Handshake, and Retry packets containing a TLS handshake on Stream 0.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </ins> 3.3. <ins> The cleartext TLS handshake may contain Server Name Indication (SNI) RFC6066, by which the client reveals the name of the server it intends to connect to, in order to allow the server to present a certificate based on that name.  It may also contain information from Application-Layer Protocol Negotiation (ALPN) RFC7301, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. Work is currently underway in the TLS working group to encrypt the SNI in TLS 1.3 TLS-ENCRYPT-SNI, reducing the information available in the SNI to the name of a fronting service, which can generally be identified by the IP address of the server anyway.  If used with QUIC, this would make SNI-based application identification impossible through passive measurement. 3.4. </ins> The QUIC Connection ID (see rebinding) is designed to allow an on- path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the

Related discussion:
text: Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.