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

From: "Christopher Wood" <[email-masked]>
Date: Fri, 24 Jan 2020 21:07:12 -0800

We'd like to move draft-ietf-tls-tlsflags [1] along. To that end, we ask that interested parties please review the document and send feedback to the list. You may also send feedback to the document repository [2]. 

Assuming no substantial or controversial issues arise, we'll start WGLC shortly thereafter, aiming to finish before IETF 107.

Thanks,
Chris, on behalf of the chairs

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
[2] https://github.com/tlswg/tls-flags

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Jan 2020 19:57:58 +0200

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.

Yoav

[1] https://github.com/tlswg/tls-flags/issues/1
[2] https://github.com/tlswg/tls-flags/pull/2

> On 25 Jan 2020, at 7:07, Christopher Wood <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Jan 2020 20:08:39 +0000

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

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!

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.

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.

Cheers,
S.

> 
> Yoav
> 
> [1] https://github.com/tlswg/tls-flags/issues/1 [2]
> https://github.com/tlswg/tls-flags/pull/2
> 
>> We'd like to move draft-ietf-tls-tlsflags [1] along. To that end,
>> we ask that interested parties please review the document and send
>> feedback to the list. You may also send feedback to the document
>> repository [2].
>> 
>> Assuming no substantial or controversial issues arise, we'll start
>> WGLC shortly thereafter, aiming to finish before IETF 107.
>> 
>> Thanks, Chris, on behalf of the chairs
>> 
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ [2]
>> https://github.com/tlswg/tls-flags
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hubert Kario <[email-masked]>
Date: Fri, 31 Jan 2020 13:26:55 +0100

> same rule as for extensions.

well, if the specification says that it can include 2040 flags, an 
implementation
must be able to process such an extension

if the idea of this extension is to reduce the size of ClientHello (the 
utility
of which I find questionable), then I don't see a situation where we will 
really
need to send old and new extensions at the same time as likely – I expect 
that
if we do allow 2040 flags, the extension in 10 or 20 years will commonly 
include
just few set bits and plenty of zeros – wasting bandwidth again
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Jan 2020 16:00:39 +0200

> On 30 Jan 2020, at 22:08, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

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.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 31 Jan 2020 16:11:32 +0200

> On 31 Jan 2020, at 14:26, Hubert Kario <[email-masked]> wrote:
> 
> well, if the specification says that it can include 2040 flags, an implementation
> if the idea of this extension is to reduce the size of ClientHello (the utility
> of which I find questionable), then I don't see a situation where we will really
> need to send old and new extensions at the same time as likely – I expect that
> if we do allow 2040 flags, the extension in 10 or 20 years will commonly include

An implementation need only support up to the last bit that is meaningful to it.  If the last feature it supports is number 30, there’s no need to read any of the octets beyond the fourth

I think that we can help the situation by partitioning the space as follows:
 - First octet is for standards-track documents coming out of TLS where the draft specifically requests such assignment.  Like if we ever need a renegotiation_info again.
 - Octets 2-4 are for other standards-track documents.
 - Octets 5-7 are for experimental drafts. They don’t get re-assigned if they later become standards track
 - Octets 8 are reserved-private
 - Octets beyond that are in case we need more.

With some luck and some care, most ClientHellos will need no more than the first 4 bytes.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 31 Jan 2020 17:36:52 +0200

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

> > much smaller number of flags - 63 should be plenty

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

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

---

From: "John Levine" <[email-masked]>
Date: 31 Jan 2020 15:48:20 -0000

test only
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly