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 messages are always sent, with
> Certificate+CertificateVerify being omitted if there is no
> certificate.

Oh, yeah, looks like there is always Finished. Does not simplify
implementation in any way (just makes implementation even more
complex).

Then on topic of 0-RTT, how does 0-RTT key hashes behave if
handshake is restarted (main handshake hash continues, but
0-RTT hash context currently needs to be separate from the
main context)?


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 if there is no
certificate.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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
> > "0RTT" any more.
> 
> There is a Finished message in the client's first flight.  It's before
> the early data.

Only if using 0-RTT auth, which seems is going to be removed (yay).

However, one still can't tamper with timestamp in ClientHello: The
ClientHello affects the 0-RTT encryption keys and 0-RTT decrypt failure
(as opposed to not being able to derive 0-RTT keys) is a fatal error
(no fallback).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 record protection afterwards.  Same as TLS has always done.
It's basic SIGMA.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 the benefit? it's
> not
> > "0RTT" any more.
>
> There is a Finished message in the client's first flight.  It's before
> the early data.
>
> https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2


Sorry, I thought that Finished message disappeared due to concerns over not
including any server data. That makes more sense of it; though I'll note
that it relies on basically a Mac-Then-Encrypt construction.



-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 flight.  It's before
the early data.

https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 being part of the session transcript.
> It will be authenticated by the Finished message included by the
> client, by the key derivation, and ultimately by the remainder of the
> 1RTT handshake.
>

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.

>
> > * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I
> > guess) ?
>
> No.  The server records the time that it generates the ticket.  Then
> that ticket travels to the client (1/2 RTT).  At that point the
> counter starts.  Then, on resumption, the client stops the clock and
> sends the message to the server (1/2 RTT).
>

Makes sense!


-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 in many cases,
NewSessionTicket is generated in response to something in the client's
first flight, but that's not a guarantee.

> It's also important exactly where and when the server checks the timestamp. 
> If the timestamp is solely checked upon receipt of the client hello, an 
> attacker can slowly trickle replayed 0-RTT data to the server, which somewhat 
> defeats the point of a very narrow replay window (with a 1 second window, the 
> connection must be opened with 1 second, but the application data could 
> actually get delivered minutes later).

If you want to handle the pathological cases, feel free to propose mitigation.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 very tight
> time
> > limit of when the server provided a resumption ticket/configuration?
>
> No.  If we accept Stephen's suggestion and go to milliseconds (I will
> do that), then the maximum age of a ticket is just over 7 weeks.  Much
> longer than the time we allow a resumption ticket to live.
>

i did mis-understand so; I read your PR as suggesting that the server
should impose a small limit on the elapsed time itself.

But now I think what you're saying is this; the server should check that
the same amount of time (modulo an RTT) has elapsed on both the client and
the server. A few other questions;

* How is the elapsed time on the wire authenticated? can't an attacker
modify it and replay?
* Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I
guess) ?
* Clock drift; especially on clients, seems like a real problem here - how
tight would realistic tolerances be?

-
 Colm



-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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 include 1 round trip.

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson
Sent: Tuesday, March 29, 2016 6:29 AM
To: tls@ietf.org
Subject: [TLS] Narrowing the replay window

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 make.  Now, your exposure to 
replay is much less.

It's not ironclad, since the server needs to account for a round trip, but I 
think that would could probably get the window down to single-digit seconds.

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=CwICAg=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=yV13qQWQtVr_en1cI1kcs4zRx07qsOQ4PNkMQFvEIQw=XQHs_Zge-MaIU6aeUJxO3PTm-2SGhf8O-AAoRKk_vws=
 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls