Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

[Hubert Kario <[e-mail]>]

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