On 5/20/2021 5:28 AM, Viktor Dukhovni wrote:
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
> SVCB's syntax would need us to not only exclude non-ASCII characters but
> also avoid random delimiters like commas, right? I think that's going a bit
> too far. As Ryan notes, complex definitions for allowed strings result in
>
On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
> wrote:
>
> > 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
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex definitions for allowed strings result in
ambiguities around who is responsible for validating what and subtle
On Thu, May 20, 2021 at 6:30 AM Salz, Rich wrote:
> Look at RFC 701, it says: the precise set of octet values that identifies
> the protocol. This could be the UTF-8 encoding of the protocol name.
>
> So I changed my mind and think it's okay to leave as-is but wouldn't mind
> if it became less
Look at RFC 701, it says: the precise set of octet values that identifies the
protocol. This could be the UTF-8 encoding of the protocol name.
So I changed my mind and think it's okay to leave as-is but wouldn't mind if it
became less general or more specific. For example, what if a protocol
For better or worse, these identifiers are being used in places outside the TLS
handshake -- for example, in HTTP header fields, as Erik mentioned. That brings
the encoding / conversion concerns he mentioned. It would be simpler (and
likely safer) to only allow ASCII strings in those uses (at
On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
wrote:
> 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
>
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
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
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.
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
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
13 matches
Mail list logo
