Subject: [TLS] Narrowing the replay window

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Mar 2016 21:29:10 +1100

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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Mar 2016 12:32:09 +0100

> but I think that would could probably get the window down to

In an offlist exchange with Martin, I suggested allowing
finer granularity than 1s, e.g. 1ms. I'm not sure how
practically useful that would be, but I don't think it'd
constitute much of a new fingerprinting risk (as the
ticket bytes identify all the genuine 0rtt requests from
the same client anyway) and it might provide some clients
and servers with a way to reduce the possible harm even
more.

Cheers,
S.

> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Kyle Nekritz <[email-masked]>
Date: Tue, 29 Mar 2016 17:45:08 +0000

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:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, March 29, 2016 6:29 AM
To: [email-masked]
Subject: [TLS] Narrowing the replay window

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
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=yV13qQWQtVr_en1cI1kcs4zRx07qsOQ4PNkMQFvEIQw&s=XQHs_Zge-MaIU6aeUJxO3PTm-2SGhf8O-AAoRKk_vws&e=

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 29 Mar 2016 21:49:16 +0300

> but I think that would could probably get the window down to

Is this intended to be somehow compatible with off-band configurations?
I recall off-band configurations were stated as reason for having
absolute instead of relative time in configurations.

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 29 Mar 2016 12:53:38 -0700

> but I think that would could probably get the window down to

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?
If so - is that really useful? over that kind of time length, wouldn't it
be especially beneficial to simply keep the original connection open for a
bit longer? I thought that an intent of 0RTT is that it can save time even
when you're connecting to a server maybe hours (days?) after you originally
did.

Separately; is there a mechanism to prevent an attacker from changing the
elapsed time value?

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 10:37:14 +1100

On 29 March 2016 at 22:32, Stephen Farrell <[email-masked]> wrote:
> 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, Kyle Nekritz <[email-masked]> wrote:
> 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).

Unfortunately, there is no client message that solicits the
NewSessionTicket.  The message can be sent spontaneously by a server
at any time.

> Is this intended to be somehow compatible with off-band configurations?

If an out of band configuration is used, then we would need a rule for
establishing the time that elapsed_time starts from and new rules
about tolerances.  This isn't going to be compatible straight off.

On 30 March 2016 at 06:53, Colm MacCárthaigh <[email-masked]> wrote:
> 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.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 29 Mar 2016 17:30:34 -0700

On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson <[email-masked]>
wrote:

> time

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 12:25:47 +1100

> * How is the elapsed time on the wire authenticated? can't an attacker

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.

> * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I

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).

> tight would realistic tolerances be?

Clock drift over this time frame is a small problem, but one that can
be managed by having a small allowance for drift.  In my experience,
drift is likely to be small enough that errors in RTT measurement are
more likely to dominate [47][48].  What is more likely to be a problem
is time corrections during that time (via NTP for instance).

In any case, these sorts of errors fail soft.  You just lose 0-RTT.

[47] I have seen drift in the order of seconds per day, but that is
rare.  Those users will find lower rates of 0-RTT acceptance, or 0-RTT
will only work over shorter periods.  That's not great, but we can't
always win.  Most clock errors are simple "I didn't even setup NTP"
sort of problems.

[48] Users with high round trip variability will suffer too.  That's
very common in developing countries, and on wireless networks.

---

From: Kyle Nekritz <[email-masked]>
Date: Wed, 30 Mar 2016 01:45:50 +0000

> Unfortunately, there is no client message that solicits the NewSessionTicket.  The message can be sent spontaneously by a server at any time.

The time since the client hello was sent/received can still be used if it is stored after opening the connection.

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).

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, March 29, 2016 7:37 PM
To: Colm MacCárthaigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Narrowing the replay window

On 29 March 2016 at 22:32, Stephen Farrell <[email-masked]> 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.

> 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 clien…

Unfortunately, there is no client message that solicits the NewSessionTicket.  The message can be sent spontaneously by a server at any time.

> Is this intended to be somehow compatible with off-band configurations?

If an out of band configuration is used, then we would need a rule for establishing the time that elapsed_time starts from and new rules about tolerances.  This isn't going to be compatible straight off.

On 30 March 2016 at 06:53, Colm MacCárthaigh <[email-masked]> 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.

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=I9v9EWiJOFgT_atsbsPa_psibxuW6GdsLVEjN1MLvfY&s=6lVaBATyEochJpNSfU-oBmPKNSil7MtIklKFbKqJfM8&e=

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 12:48:23 +1100

> 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 t…

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 29 Mar 2016 18:49:28 -0700

> client, by the key derivation, and ultimately by the remainder of the

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.

> sends the message to the server (1/2 RTT).

Makes sense!

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 12:52:23 +1100

On 30 March 2016 at 12:49, Colm MacCárthaigh <[email-masked]> 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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 29 Mar 2016 20:18:52 -0700

On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson <[email-masked]>
wrote:

> message

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 14:52:19 +1100

On 30 March 2016 at 14:18, Colm MacCárthaigh <[email-masked]> 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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Mar 2016 08:15:54 +0300

> There is a Finished message in the client's first flight.  It's before

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Mar 2016 20:35:31 +1100

> 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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Mar 2016 21:56:32 +0300

> Certificate+CertificateVerify being omitted if there is no

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