Re: [TLS] Backwards-compatibility of 0-RTT data

2016-01-26 Thread David Benjamin
On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla wrote: > On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin > wrote: > >> Instead of putting 0-RTT data in a ClientHello extension, the current >> draft has the client send extra records in the first flight, right? (I see >> an early_data extension, but

Re: [TLS] Backwards-compatibility of 0-RTT data

2016-01-26 Thread Martin Thomson
On 27 January 2016 at 13:11, Eric Rescorla wrote: > Well, I think we're generally encouraging people to have to explicitly > enable 0-RTT. I think that the key point was that you would have to explicitly enable 0-RTT AND that also meant a commitment not to choke on 0-RTT data for at least as lon

Re: [TLS] Backwards-compatibility of 0-RTT data

2016-01-26 Thread Eric Rescorla
On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin wrote: > Instead of putting 0-RTT data in a ClientHello extension, the current > draft has the client send extra records in the first flight, right? (I see > an early_data extension, but it seems only be an indicator. There's also > mention of requi

[TLS] Backwards-compatibility of 0-RTT data

2016-01-26 Thread David Benjamin
Instead of putting 0-RTT data in a ClientHello extension, the current draft has the client send extra records in the first flight, right? (I see an early_data extension, but it seems only be an indicator. There's also mention of requiring trial decryption which only makes sense if it were appended.