Re: [TLS] Feedback on draft-ietf-tls-tlsflags

[Ilari Liusvaara <[e-mail]>]

On Fri, Jan 31, 2020 at 04:00:39PM +0200, Yoav Nir wrote:
> 
> 
> > On 30 Jan 2020, at 22:08, Stephen Farrell <[e-mail]> wrote:
> > 
> > 
> > 
> > On 30/01/2020 17:57, Yoav Nir wrote:
> >> Hi folks.
> >> 
> >> In case you’re not following GitHub, there was an issue with a brief
> >> discussion ([1]) and a resulting pull request ([2]).
> >> 
> >> If there are no objections by late next week, I will merge the PR.
> > 
> > Allowing 2040 flags seems a bit mad and a possible
> > foot-gun - with a specification required rule that
> > could end up worse than the ciphersuites registry!

Well, TLS allows tens of thoursands of extensions, and the extension
registry does not look even nearly as bad as ciphersuite registry.

This has multiple possible reasons:

- Much harder to specify extensions.
- Less "vanity" stuff with extensions.
- No bad combinatorics (ciphersuites were horrible combinatorics-wise
  before being reworked in TLS 1.3).


> > Given it's possible to define a tls_flags2 extension
> > if this one runs out, I'd argue to constrain this to a
> > much smaller number of flags - 63 should be plenty
> > I'd say.

One would not want any high-numbered flags, so splitting to multiple
extensions if there would be many flags would likely be benefical
size-wise.

One could support 64 flags with size bound of 12 bytes (8 bytes plus
4 byte extension overhead). Note that 64 is more than number of all
TLS extensions ever registered (let alone number of flaglike TLS
extensions).

> > That said, it's not that huge a deal since I have
> > a hard time seeing implementers even trying to code
> > for 2040 flags and specification required is the
> > same rule as for extensions.

Note that it would not be much harder to make an extension than a flag.
It would pretty much just specifying the extension as blank. One needs
to specify the semantics anyway.

> The format allows 2040 bits. I think we should never define that many
> bits. I think we should never define even 60 bits. But I also think
> it should be left up to the TLS chairs and the IANA experts to serve
> as gatekeepers rather than tying their hands in the specification.

Note that the length field is completely redundant and could be
removed, saving 1 byte.

And I think that even defining 16 flags (to exceed 6 bytes) will take a
while (that is more than all flag-type extensions that exist to date).

And probably there should not be any reserved entries, just all
"specification required". Or maybe some low number entries (0-7?) for
"standards action" (mostly to be used for any possible security fix
extensions)?


-Ilari