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 messages are always sent, w
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 if there is no
certificate
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
> > "0RTT" any more.
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 record protection a
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 the benefit? it's
> not
> > "0RTT" any more.
>
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 flight. It's before
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 being part of the session transcript.
> It will b
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 in many cases,
New
t be opened with 1 second, but the application data could
actually get delivered minutes later).
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, March 29, 2016 7:37 PM
To: Colm MacCárthaigh
Cc: tls@ietf.org
Subject: Re: [TLS] Narrowing
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 being part of the session transcript.
It will be authenticated by the Finished message included by the
client, by t
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 very tight
> time
> > limit of when the serve
On 29 March 2016 at 22:32, Stephen Farrell wrote:
> In an offlist exchange with Martin, I suggested allowing
> finer granularity than 1s, e.g. 1ms.
I think that this is reasonable. This might allow for tighter
tolerance for drift, which means less replay opportunity.
On 30 March 2016 at 04:45,
On Tue, Mar 29, 2016 at 3:29 AM, Martin Thomson
wrote:
> https://github.com/tlswg/tls13-spec/pull/437
>
> In short, have the client report the time since it received the
> configuration. Then have the server reject early data if the time
> doesn't match.
>
> I think that this is a relatively eas
On Tue, Mar 29, 2016 at 09:29:10PM +1100, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/pull/437
>
> In short, have the client report the time since it received the
> configuration. Then have the server reject early data if the time
> doesn't match.
>
> I think that this is a relat
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 include
On 29/03/16 11:29, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/pull/437
>
> In short, have the client report the time since it received the
> configuration. Then have the server reject early data if the time
> doesn't match.
>
> I think that this is a relatively easy change to
16 matches
Mail list logo
