Subject: [quicwg/base-drafts] Make ALPN mandatory in QUIC-via-TLS (#2263)

From: Victor Vasiliev <[email-masked]>
Date: Thu, 27 Dec 2018 05:23:08 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 27 Dec 2018 08:16:36 -0800

Is this not already the case? In transport section 7 is says:

> QUIC provides reliable, ordered delivery of the cryptographic handshake data. QUIC packet protection is used to encrypt as much of the handshake protocol as possible. The cryptographic handshake MUST provide the following properties:
> <snip>
> * authenticated negotiation of an application protocol (TLS uses ALPN [RFC7301] for this purpose)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450182149

---

From: Marten Seemann <[email-masked]>
Date: Thu, 27 Dec 2018 08:18:58 -0800

This doesn't require the endpoints to actually use the ALPN, does it?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450182624

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 27 Dec 2018 08:24:54 -0800

A little earlier section 7 says:

> Version 0x00000001 of QUIC uses TLS as described in [QUIC-TLS];

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".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450183960

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Dec 2018 10:26:32 -0800

@vasilvv 
> 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. Si…

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.

@LPardue My interpretation would be the same as @marten-seemann, that the intent of the text is to state that the handshake protocol must protect the protocol negotiation _when_ it is negotiated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450205280

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 27 Dec 2018 11:16:45 -0800

@kazuho 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450213244

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 18:19:33 -0800

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 @kazuho's and @LPardue's 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 @kazuho, I don't believe that the text explicitly mandates that the protocol negotiation facility be *used*, so I'd like to add that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450601866

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 30 Dec 2018 18:58:57 -0800

Sgtm

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2263#issuecomment-450603496