> On 26 Mar 2019, at 18:49, Hubert Kario <hka...@redhat.com> wrote: > > On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote: >>> On 26 Mar 2019, at 14:45, Hubert Kario <hka...@redhat.com> wrote: >>> >>> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote: >>>> Hi. Today at the TLS meeting, there was a discussion at the mic about >>>> 1-bit extensions that only serve to indicate support for an optional >>>> feature. EKR commented that such extensions take 4 bytes each and that >>>> maybe we need to replace them with a flags extension. >>>> >>>> So I threw together a quick -00 draft with an extension that does just >>>> that >>>> [1]. >>>> >>>> Comments are welcome. >>> >>> I don't think that "penny-pinching" the 4 bytes necessary to send a flag >>> is >>> worth the interoperability problems, and increased complexing of parsing >>> Client Hello. Especially if we go the route of actual bit flags. >> >> Right. Which is why I went with a 1-byte encoding rather than a bitstring. >> >>> I think the likelihood of bugs in that code over the possible bytes saved >>> makes it a net negative. >> >> I don’t think so. My encoding is not all that complex. >> >>> yes, TLS is quite chatty protocol, it could encode values much more >>> tightly, but I think we all remember the bugs related to ASN.1 parsing >>> from inside of PKCS#1 v1.5 signatures >> >> Complexity is on a spectrum. DER encoding is pretty far on this spectrum. >> A list of 1-octet identifiers is on the other end. A bitstring is more >> complex than the identifier list, but not anywhere near DER. > > 1-octet identifiers may not be considered extensible enough > (yes, you can add another extension, but the first extension to use it will > be > paying an additional price of 2 bytes on top of the extension overhead; same > if you just need to use only one flag, then you are paying the same price for > every connection) > > 2-octet identifiers asymptotically approach 2-octet saved per flag, which is > about 50% saved per flag, I don't see it as much > > to approach it from another way: while I think we will, sometime in the > future, reach a situation when we have few hundred flag extensions *defined* > , > I do not see a future in which we will need to *use* more than few dozen flag > extensions in any real world client. So we are talking about a possible > saving > of around 100 bytes in ClientHello (36 extensions * 3 bytes saved) in this > proposal
A few dozen? I was thinking under 10 in a typical client. > won't this be completely erased by any post-quantum key share? I think implementing (or not) draft-ietf-tls-certificate-compression would have a much more significant effect than anything we save here. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
