Draft: draft-ietf-quic-tls

Commentary: The transport already requires that the cryptographic handshake provide authenticated negotiation of application protocol . However , the TLS doc was a little weak on whether ALPN should be used . This clears that up . 
 Authenticated application protocol 
 One suggestion . 
 TCP - based protocols have historically had a lot of issues with protocol confusion , where one protocol could be interpreted as another and that lead to security issues ; that lead to various ways of working that issue around , sometimes quite ugly ( e.g.  ) . The root issue in TCP or regular UDP is that the application protocol is multiplexed by the port , but the port is never a certain indicator of the protocol . ALPN , on other hand , is exactly that . Since there are no b / c concerns in our case , can we make ALPN mandatory in QUIC ? This could save us a lot of security issues down the road . 
 Is this not already the case ? In transport section 7 is says : 
 This does n't require the endpoints to actually use the ALPN , does it ? 
 A little earlier section 7 says : If the TLS handshake fails to provide ALPN , or some other TLS - compatible negotiation method ( of which I know none ) , I 'd interpret that as failing the required condition of " MUST provide authenticated negotiation " . 
 I would be concerned of the side - effects that we might have . RFC 7301 ( ALPN ) requires Expert Review for registering new application protocols . My concern is that mandating the " use " of ALPN might forbid QUIC being used in in - house protocols . My interpretation would be the same as that the intent of the text is to state that the handshake protocol must protect the protocol negotiation when it is negotiated . PS . OTOH I do agree that H3 MUST require the use of ALPN , as H2 does . 
 I do n't see read any optionality , so perhaps this is the ambiguity in the spec . ( FWIW optionality of client authentication is explicitly highlighted in that section ) . I also share your concerns about mandating ALPN . There still seem to be a few open questions about de - multiplexing different UDP - based protocols when a server listens on the same port - how does ALPN for QUIC mitigate that ? We also have WIP like DATAGRAM frame that are proposing use of TP for enabling the transport - layer feature that could be used by an application to talk arbitrary protocols . It seems like ALPN is too rigid a model to support multiple application layers within a single QUIC connection . 
 I 'm OK with the proposed requirement . Using ALPN protects you from others . Not using ALPN might make you ulnerable to weird cross - protocol attacks . However , I take and points collectively as " if ALPN2 is better , mandating ALPN specifically might be bad " . I 'm OK with loosening the straps on registrations a little ( maybe just for < N character names ) there if that 's the only real concern . Would people be OK with " explicit protocol negotiation , such as ALPN " ? Like I do n't believe that the text explicitly mandates that the protocol negotiation facility be used , so I 'd like to add that . 
 Sgtm 
 I do n't know enough about ALPN , but if QUIC does n't handle inhouse protocols well without bureaucracy , ALPN will get abused . What about future ? decentralised approaches e.g. via DNS records ? 
 The general requirement SG , though I assume you 'd still have to spell out the TLS specifics in the TLS mapping document . I do not expect the Expert Review requirement to be a particularly strong barrier since from what I understand the bar is " the designated experts do not consider you obviously bogus " . Either way I think we can discuss within TLS working group about relaxing some of those . 
 I think requiring some form of explicit protocol negotiation would be good . The TLS draft could potentially be a bit more specific about what that looks like , too , but I agree that we do n't want to be too restrictive here . In other words , what said above sounds good to me . 
 SGTM . I think that the concern will be resolved if we adopt proposal . You would not be required to send ALPN for example when name resolution with combined protocol negotiation is being used . 
 The transport doc currently says : So I think that is fine . I 've opened to make the ALPN requirement clearer . As says , if you have other means of agreeing on protocol , then you can avoid ALPN . For instance , a QUIC version that could only be used with one application protocol would be one way . In the end , you have to be sure that both client and server agree on what protocol they are talking . I can see how binding to name resolution would work ; though I can also see how it might not work ( multiple subjectAltNames , failing to communicate SNI properly , coalescing , etc ... ) .
Paragraph (version A):
TLS uses Application Layer Protocol Negotiation (ALPN) RFC7301 to
select an application protocol.  The application-layer protocol MAY
restrict the QUIC versions that it can operate over.  Servers MUST
select an application protocol compatible with the QUIC version that
the client has selected.
Paragraph (version A):
If the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection.  A client
MUST abort a connection if the server picks an incompatible
combination of QUIC version and ALPN identifier.
Paragraph (version B):
QUIC requires that the cryptographic handshake provide authenticated
protocol negotiation.  TLS uses Application Layer Protocol
Negotiation (ALPN) RFC7301 to select an application protocol.  Unless
another mechanism is used for agreeing on an application protocol,
endpoints MUST use ALPN for this purpose.
Paragraph (version B):
An application-layer protocol MAY restrict the QUIC versions that it
can operate over.  Servers MUST select an application protocol
compatible with the QUIC version that the client has selected.  If
the server cannot select a compatible combination of application
protocol and QUIC version, it MUST abort the connection.  A client
MUST abort a connection if the server picks an incompatible
combination of QUIC version and ALPN identifier.