On Monday 21 September 2015 00:20:21 Dave Garrett wrote: > On Sunday, September 20, 2015 10:59:58 pm William Whyte wrote: > > might be worth increasing the maximum extension size to 2^24-1 for > > TLS 1.3. > No, I don't think the limit can be raised. The general ClientHello > format has to stay frozen for interoperability with other versions, > and unless I'm misreading things, the size of the length of a vector > can't change. A separate message seems like what would be needed to > have a larger first-flight payload. (and any new messages would need > to be signaled via an extension, though it could have a 0-length > payload)
we still would need to wait for server to reply before we could send them, so no way to do 1RTT > > Is there a strong reason for keeping the maximum size at 2^24-1, > > other than saving one byte on all the relevant length fields? > > Typo? Did you mean "keeping the maximum size at 2^16-1"? > > 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). That limitation is present since RFC 3546 [Extensions], which explicitly says: This overrides the "Forward compatibility note" in [TLS]. -- 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
