On Monday 21 September 2015 15:04:17 Dave Garrett wrote: > On Monday, September 21, 2015 07:22:03 am Hubert Kario wrote: > > On Monday 21 September 2015 00:20:21 Dave Garrett wrote: > > > A strong reason is it not being possible to change due to the need > > > for TLS 1.3 clients to be able to connect to TLS 1.2 servers that > > > won't understand a format change. Even if it were technically > > > possible, I wouldn't expect all implementations to safely handle > > > it. > > > > the TLS1.2 standard says that the ClientHello MUST match either > > extension-less or an extension-present format and server MUST check > > that the overall length of message matches the processed data, so > > we can't have extensions-after-extensions (which theoretically > > could have 3 byte length field). > > Yeah, adding a second extensions vector in addition to the existing > one was my other thought, but it's too messy for me to think it'd be > worth trying. Looks like that's not even possible. I think we're > stuck with the current TLS extension size limits forever. > > I doubt anyone would really want to use any keys in the megabyte range > anyway. Post-quantum crypto research/experimentation for TLS & other > network protocols should really focus on systems with smaller keys. > Even if a giant-key scheme was ideal, you'll have a very hard time > convincing people to actually use it, no matter how much they might > need it. :/
true, that being said, I can see 64KiB total being limiting for different stuff in the future and while sending 2MiB packets as "just a hello" is unlikely, I can see us sending 64KiB or 128KiB packets... maybe we should reintroduce the forwards compatibility clause for client hello? it won't help us now, but when TLS1.2 gets broken then we'll be able to move forward with higher sizes for extensions (whatever that happens) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
