Change:
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. WebSockets). 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 doesn'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".
NAME 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. NAME My interpretation would be the same as NAME 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.
NAME I don'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 NAME and NAME 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 NAME I don't believe that the text explicitly mandates that the protocol negotiation facility be used, so I'd like to add that.
Sgtm
I don't know enough about ALPN, but if QUIC doesn't handle inhouse protocols well without bureaucracy, ALPN will get abused. What about future? decentralised approaches e.g. via DNS records?
NAME The general requirement SG, though I assume you'd still have to spell out the TLS specifics in the TLS mapping document. NAME 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 don't want to be too restrictive here. In other words, what NAME said above sounds good to me.
NAME SGTM. NAME I think that the concern will be resolved if we adopt NAME 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 NAME 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...).

Discussion:
version downgrade prior to the completion of the handshake, though it means that a downgrade causes a handshake failure. <del> 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. If the server cannot select a compatible combination of application </del> <ins> 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. 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 </ins> 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.