On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote: > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote: > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson > > <[email protected]> wrote: > > > On 22 June 2016 at 12:01, Watson Ladd <[email protected]> wrote: > > >> Why isn't 0-RTT an extension in the Client Hello to deal with this? > > > > > > You can't stream extensions, which unfortunately is required given how > > > most software interacts with their TLS stack. > > > > A few months ago we had a lengthy discussion on the list and at TRON > > about how risky 0-RTT is. This culminated in the idea that 0RTT data > > should be provided through a distinct channel to the application, > > along with feedback about whether it was not accepted. If we're > > willing to change the interaction pattern to support that, we can > > accommodate using 0RTT as an extension by gathering it all and sending > > when the handshake happens. But it sounds like you are discussing a > > design where the handshake fakes completion if 0-RTT is on, and at > > some point later "well, i didn't actually send the data you wanted > > to". Or am I missing something about the API design that is motivating > > this streaming approach? > > Sticking 0-RTT data into ClientHello also has the following problems: > - One needs to mangle ClientHello (strip an extension on receiver side) > to obtain hash suitable for key derivation for 0-RTT. To do it any > other way either doesn't work, or are cryptographically quite risky. > - It bloats ClientHello, something you rather not bloat, especially > with DTLS.
here's a crazy idea: - introduce a new extension which has meaning of "more data follows" - if the server finds it, it expects another Handshake Protocol message from the client - the client sends a new "ClientHelloExtension" message that includes additional data, in practice it's continuation of the extension list (just let's use 3 byte length fields in the structure) the obvious downside is, that TLSv1.2 servers do not support it now the upsides are: * TLSv1.2 servers can be fairly easily updated to support it but ignore it (just feed the next message to handshake hash, but not interpret it) - that fixes the upgrade scenario and allows the process to be performed in two steps, either of which can then be safely reversed * makes it possible in the future, if we are forced to, support post quantum crypto that requires key shares that won't fit in current extensions field -- Regards, Hubert Kario Senior 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
