Re: [TLS] Recommending ALPN / backwards compatibility

[[e-mail]]

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?

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

Maybe it would be useful to specify an "empty"/"dummy" protocol,
which just states case 2, e.g., "NOMATCH"?

-- 
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.