> On 31 Jan 2020, at 14:26, Hubert Kario <hka...@redhat.com> wrote: > > On Thursday, 30 January 2020 21:08:39 CET, Stephen Farrell 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! >> >> 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. > > 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
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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
