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
--
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
