Leave ALPN negotiation to ALPN

[martinthomson]

The draft (formerly RFC) says:

If the connection to the alternative service does not negotiate the expected protocol (for example, ALPN fails to negotiate h2, or an Upgrade request to h2c is not accepted), the connection to the alternative service MUST be considered to have failed.

The HTTPS (or SVCB) record definition is far more careful about how it manages the use of ALPN. The most important piece to that is that it talks only about what the client offers to a server based on what is in HTTPS/SVCB records. For SVCB, clients are required to list all compatible protocols that it is willing to use when making a connection, even if the record (here: field/frame) does not identify that protocol.

The reason for that is that there is a potential downgrade attack in play if the client does not list (or accept) protocol versions that it considers to be superior. Take the case of an Alt-Svc advertisement that lists "http/1.1". A client might establish a connection to that service only to discover that the server supports the (arguably better) "h2" protocol. As currently defined, Alt-Svc requires the client to abandon that connection.

As servers might deploy new and better protocols over the lifetime of an Alt-Svc cache, this means that clients are forced to abandon perfectly good connections. To avoid that, they might choose to remove more-preferred ALPN IDs when connecting, which would be bad as it means that Alt-Svc has been used to force a downgrade.

We consider Alt-Svc to be authentic, so this is a low-risk downgrade. We should still allow for the possibility that an attacker is able to inject Alt-Svc. The current system ensures that an attacker can bypass DNS-level checks (full disclosure: I don't put much weight on these), but additionally ensures that an attacker can force a protocol of their choice to be used.

Alternative services should be aligned with the SVCB approach, requiring that clients accept the outcome of TLS ALPN negotiation.

That doesn't mean that clients are prevented from applying policy to Alt-Svc connections. For instance, I understand that Chrome does not make connections to alternatives unless the protocol on offer meets some minimum bar for performance/security/whatever. That's a perfectly reasonable thing to do, so we should expressly allow clients to apply similar constraints.