Subject: Re: [TLS] Recommending ALPN / backwards compatibility

From: <[email-masked]>
Date: Sat, 8 May 2021 11:11:11 +0200

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.

---

From: "Filippo Valsorda" <[email-masked]>
Date: Sat, 08 May 2021 09:26:10 -0400

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

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

---

From: Stefan Hagen <[email-masked]>
Date: Sat, 8 May 2021 16:53:40 +0200

> Am 08.05.2021 um 15:27 schrieb Filippo Valsorda <[email-masked]>:
> 2021-05-08 05:11 GMT-04:00 [email-masked]:
>> On Fri, Apr 30, 2021, Martin Thomson wrote::
>> [...]
The equivalence is true for the IETF bubble we discuss in. Outside - or in other bubbles like ISO - SHALL is a requirement on an active participant while MUST is more an environmental condition where no single responsibility is easily assigned for all cases (or that single power is outside of scope and reach for the prose).

In OASiS specs we try to either adhere to the IETF conventions and do not differentiate between SHALL and MUST or - when targeting ISO standardization beyond OASIS Standard stage adhere to the ISO terms, which may also fit the ITU/ETSI bubble terms.

I would not consider the phonetic similarity unfortunate, as long as words like too occur in the surrounding language ;-)

All the best,
Stefan