Subject: What to do when ALPN negotiation fails?

From: Alessandro Ghedini <[email-masked]>
Date: Mon, 4 Mar 2019 15:24:18 +0000

Hello,

PR#2314 added a requirement for end-points to close a connection if the ALPN
negotiation fails, but it doesn't say which error needs to be used.

RFC7301 says:

  In the event that the server supports no protocols that the client advertises,
  then the server SHALL respond with a fatal "no_application_protocol" alert.

So it seems to follow that QUIC servers would have to send a 0x1XX error with
whatever value the no_application_protocol alert has.

However RFC7301 only defines server behaviour (since in TLS ALPN is not
mandatory), but it doesn't forbid clients to send that alert either, and for
QUIC's purposes it seems better to use the same error on both sides.

Anyway, all of this to say that I created an issue to clarify all this [0], and
written up a PR [1] that makes both sides send the no_application_protocol
alert.

Thoughts?

Cheers

[0] https://github.com/quicwg/base-drafts/issues/2495
[1] https://github.com/quicwg/base-drafts/pull/2483

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Mar 2019 18:06:19 -0500

This seems like the right plan to me.

As much as it is awkward to go outside of the ALPN rules here, what you need to realize is that ALPN presumes a setting where failure to negotiate ALPN is the pre-existing default.  No so with QUIC, and in fact, we've recently decided to require ALPN.  Requiring ALPN as we do avoids a bunch of mess related to cross-protocol attacks, which we agree is a fine thing.