Re: [TLS] Narrowing the replay window

2016-03-30 Thread Ilari Liusvaara
On Wed, Mar 30, 2016 at 08:35:31PM +1100, Martin Thomson wrote: > On 30 March 2016 at 16:15, Ilari Liusvaara wrote: > > Only if using 0-RTT auth, which seems is going to be removed (yay). > > My reading is that Finished is always present. That is, the > authentication

Re: [TLS] Narrowing the replay window

2016-03-30 Thread Martin Thomson
On 30 March 2016 at 16:15, Ilari Liusvaara wrote: > Only if using 0-RTT auth, which seems is going to be removed (yay). My reading is that Finished is always present. That is, the authentication messages are always sent, with Certificate+CertificateVerify being omitted

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Ilari Liusvaara
On Wed, Mar 30, 2016 at 12:52:23PM +1100, Martin Thomson wrote: > On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > > But isn't that too late? If you have to wait for the client finished message > > before you can even decrypt the 0RTT section; what's the benefit? it's not

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Martin Thomson
On 30 March 2016 at 14:18, Colm MacCárthaigh wrote: > though I'll note that it relies on basically a Mac-Then-Encrypt > construction. I don't think that the right term to apply here. This isn't record protection. The MAC authenticates the handshake here, then we use AEAD for

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Colm MacCárthaigh
On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson wrote: > On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > > But isn't that too late? If you have to wait for the client finished > message > > before you can even decrypt the 0RTT section; what's

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Martin Thomson
On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > But isn't that too late? If you have to wait for the client finished message > before you can even decrypt the 0RTT section; what's the benefit? it's not > "0RTT" any more. There is a Finished message in the client's first

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Colm MacCárthaigh
On Tue, Mar 29, 2016 at 6:25 PM, Martin Thomson wrote: > On 30 March 2016 at 11:30, Colm MacCárthaigh wrote: > > * How is the elapsed time on the wire authenticated? can't an attacker > > modify it and replay? > > It is authenticated by virtue of

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Martin Thomson
On 30 March 2016 at 12:45, Kyle Nekritz wrote: > The time since the client hello was sent/received can still be used if it is > stored after opening the connection. Only if we introduce an inconsistency by asking for different handling in different circumstances. I agree that

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Colm MacCárthaigh
On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson wrote: > On 30 March 2016 at 06:53, Colm MacCárthaigh wrote: > > It's likely I'm misunderstanding, but I'll ask to clear it up. Does this > > proposal imply that a 0RTT section can only be sent within a

Re: [TLS] Narrowing the replay window

2016-03-29 Thread Kyle Nekritz
I think this will better account for the round trip delay if the elapsed_time is defined on the client as the time since the request for the session ticket (in other words, the time since the client hello was sent). That way both the server computed time and the client reported time will