[TLS] ALPN and QUIC Versions

[Martin Duke]

Hello TLS,

I just started a thread on how ALPN will interact with new versions of QUIC:
https://mailarchive.ietf.org/arch/msg/quic/VuAWMvB8XFjpfK7kg6QaHn4KHqA/

This discussion could have a large impact on the evolution of the IANA ALPN
registry, which this WG created. Please participate in the discussion if
you have thoughts or concerns.

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

[TLS] Narrowing allowed characters in ALPN ?

[Erik Nygren]

With draft-ietf-dnsop-svcb-https being in WGLC in DNSOP, one feedback that
has come up is that the escaping and parsing for SvcParamValues is
complicated.
Most of this complication comes from trying to support 8-bit clean ALPN
values.
Ideally in presentation format the ALPN list would be something like
"h2,h3,http/1.1"
but at the same time the current definition of ALPN as being a series of
binary
octets means that we need parsing and escaping rules.
When httpbis defined Alt-Svc, quite a bit of complexity showed up there
as well for supporting an 8-bit-clean ALPN value while allowing for an ascii
representation for most codepoints.  It seems likely that other
specifications
may run into the same challenge.

Would there be support for updating the ALPN registry to
indicate that registered ALPN values need to conform to a subset of token
characters?   There is a separate question for the process of making
this change, but before even exploring that it seems necessary to ask
the TLS WG if there are strong opinions on this one way or the other.

>From a usability perspective, non-token ALPN values will have challenges
in many of the systems that may try and configure them, as well
as for rendering special characters in various systems that may handle
ALPNs.
The codepoint space is also massive so it isn't clear that there's a
compelling
need to support 8-bit ALPN from a code point conservation perspective.

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

Re: [TLS] Narrowing allowed characters in ALPN ?

[Salz, Rich]

If you look at 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
 you can see that all of them are ASCII right now, except for some of the 
GREASE values.

I support limiting it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Narrowing allowed characters in ALPN ?

[Christian Huitema]

On 5/19/2021 12:29 PM, Salz, Rich wrote:


If you look 
athttps://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
  you can see that all of them are ASCII right now, except for some of the 
GREASE values.

I support limiting it.


Internationalization?

-- Christian Huitema

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

Re: [TLS] Narrowing allowed characters in ALPN ?

[Martin Thomson]

I think that we would need stronger reasons than "it's annoying".  There are 
good reasons to use octets that map to simple ASCII.  We should continue to 
only define identifiers that use those characters.  However, a specification is 
also a commitment and whether or not it was a good idea, we (this working group 
and the IETF as a whole) made that commitment.

I tend to think that as long as it isn't broken, it doesn't need fixing.  And 
we have - on various occasions - discussed using the capability.

Were we to define this all over, I'd be supportive of restrictions, but it's 
not worth fixing now.

On Thu, May 20, 2021, at 07:29, Erik Nygren wrote:
> With draft-ietf-dnsop-svcb-https being in WGLC in DNSOP, one feedback 
> that
> has come up is that the escaping and parsing for SvcParamValues is 
> complicated.
> Most of this complication comes from trying to support 8-bit clean ALPN 
> values.
> Ideally in presentation format the ALPN list would be something like 
> "h2,h3,http/1.1"
> but at the same time the current definition of ALPN as being a series 
> of binary
> octets means that we need parsing and escaping rules.
> When httpbis defined Alt-Svc, quite a bit of complexity showed up there
> as well for supporting an 8-bit-clean ALPN value while allowing for an 
> ascii
> representation for most codepoints.  It seems likely that other 
> specifications
> may run into the same challenge.
> 
> Would there be support for updating the ALPN registry to 
> indicate that registered ALPN values need to conform to a subset of token
> characters?   There is a separate question for the process of making
> this change, but before even exploring that it seems necessary to ask
> the TLS WG if there are strong opinions on this one way or the other.
> 
> From a usability perspective, non-token ALPN values will have challenges
> in many of the systems that may try and configure them, as well
> as for rendering special characters in various systems that may handle ALPNs.
> The codepoint space is also massive so it isn't clear that there's a 
> compelling
> need to support 8-bit ALPN from a code point conservation perspective.
> 
>Erik
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls
> 

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

Re: [TLS] Narrowing allowed characters in ALPN ?

[Viktor Dukhovni]

On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:

> I support limiting it.

I concur.  These are not strings used between users to communicate in
their native language.  They are machine-to-machine protocol
identifiers, and use of the narrowest reasonable character set promotes
interoperability.

We don't want to embed ASCII NUL bytes in these, worry about potential
corruption when they get embedded in text strings and undergo transforms
from ISO-Latin to UTF-8 or back, ...

The more vanilla the character set the better.  The HTTPS record
constructs comma-separated lists of these in quotes, so it has to
deal with escaping quotes and commas, and other needless pain.

We're not helping anyone by insisting that the original definition was
wise.  It can and should be revised.

-- 
Viktor.

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