Draft: draft-ietf-quic-manageability

Commentary: 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 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 does n'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 do n't have a reference for encrypting ALPN . We do n't have one . Maybe I should write one ... On the plus side , it 's something that benefits from the same techniques as  ( and less likely to cause deployment issues , though that is only because we have n'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 wo n't have people relying on stuff we might want to change .
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.