Re: [TLS] Recommending ALPN / backwards compatibility

[Filippo Valsorda <[e-mail]>]

2021-05-08 05:11 GMT-04:00 [e-mail] <mailto:ml%2Bietf-tls%40esmtp.org>:
> On Fri, Apr 30, 2021, Martin Thomson wrote:
> > An existing application protocol might not have been assigned an
> > ALPN identifier.  For other protocols the ALPN identifier might
> > not have been part of the original protocol definition, or use of
> > ALPN might have been defined originally as being optional.
> 
> Sorry for this stupid/simple question but I cannot find a way for
> a client to determine whether a server
> 
> 1. does not support ALPN.
> 2. supports ALPN but did not select a protocol.
> 
> It seems it is only possible to return a selected protocol,
> not am "empty" protocol to indicate case 2, correct?

My understanding (and the Go implementation) is that a server running an application without ALPN does not support ALPN, so it will ignore the extension (even if the TLS stack does have code to handle it).

A migration would work like this: if the client updates before the server, the client will send ALPN but it will get ignored by the server, which doesn't support ALPN yet; if the server updates before the client, the client will not send ALPN, which the server will allow (because the no_application_protocol condition is "the server supports no protocols *that the client advertises*"). Once they both updated, the server is expected to close the connection if the client sent an ALPN extension without the right protocol in it, otherwise we lose most of the cross-protocol benefit of ALPN in the first place.

> IMHO this would be useful for backwards compatibility/ migrating a
> protocol to support ALPN.  RFC 7301 states the server "SHALL" abort
> in this case:
> 
> 3.2.  Protocol Selection
> ...  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.
> 
> but that might not be a good way to support migration, which probably
> is why is just "SHALL" not "MUST"?

SHALL means MUST per RFC 2119. It's unfortunate we use a word that sounds like SHOULD to mean MUST, but that's a requirement, not a suggestion.