Re: [TLS] Recommending ALPN / backwards compatibility

[ml+ietf-tls]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Recommending ALPN / backwards compatibility

[Filippo Valsorda]

2021-05-08 05:11 GMT-04:00 ml+ietf-...@esmtp.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.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Recommending ALPN / backwards compatibility

[Stefan Hagen]

> Am 08.05.2021 um 15:27 schrieb Filippo Valsorda :
> 2021-05-08 05:11 GMT-04:00 ml+ietf-...@esmtp.org:
>> On Fri, Apr 30, 2021, Martin Thomson wrote::
>> [...]
>> 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.
> 
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___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls