Subject: [TLS] Security review of TLS1.3 0-RTT

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 07:44:35 -0700

On Sunday at the TLS:DIV workshop I presented a summary of findings of a
security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
Thanks to feedback in the room I've now tightened up the findings from the
review and posted them as an issue on the draft GitHub repo:

https://github.com/tlswg/tls13-spec/issues/1001

I'll summarize the summary: Naturally the focus was on forward secrecy and
replay. On forward secrecy the main finding was that it's not necessary to
trade off Forward Secrecy and 0-RTT. A single-use session cache can provide
it, and with the modification that ekr has created in
https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both
pre-auth and post-auth tickets, and it allows clients to build up pools of
meaningfully distinct tickets.

There's also an observation there that it should really be that clients
"MUST" use tickets only once. Any re-use likely discloses the obfuscated
ticket age, which is intended to be secret. Right now it's a "SHOULD".

On replay, the main finding is that what's in the draft is not workably
secure, and the review includes 5 different attacks against 0-RTT data to
illustrate that. Attacks 1 and 2 show that the kind of replay permitted by
the draft is very different from the kind of replay permitted by dkg's
existing downgrade-and-retry attack. I also go over why it very very
difficult to many applications to achieve that idempotency, and why one
idempotency pattern actually relies on non-replayable messages.

Attack 3 shows that idempotency is not sufficient, applications must also
be free of measurable side-effects, which is not practical.  Attack 4 shows
that 0-RTT breaks a common security mechanism: spoofing-resistant
throttles. Attack 5 shows that 0-RTT replay-ability enables an additional
form of traffic analysis.

The recommendation in the review is that implementations "MUST" prevent
replays of 0-RTT section, with some additional discussion about why the
existing advice is unlikely to be followed, and why consistent
interoperability matters here.

Unfortunately, I wasn't aware until Friday that this review would be coming
so late in the TLD1.3 draft process, and my apologies for that. I am now
planning to attend the future WG in-person meetings and look forward to
seeing many of you there.

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 May 2017 13:33:37 -0400

> On May 2, 2017, at 10:44 AM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> I'll summarize the summary: Naturally the focus was on forward secrecy and replay. On forward secrecy the main finding was that it's not necessary to trade off Forward Secrecy and 0-RTT. A single-use session cache can provide it, and with the modification that ekr has created in https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both pre-auth and post-auth tickets, and it allows clients to build up pools of meaningfully distinct tickets.
> 
> There's also an observation there that it should really be that clients "MUST" use tickets only once. Any re-use likely discloses the obfuscated ticket age, which is intended to be secret. Right now it's a "SHOULD".

Well, just a few days ago there was a discussion of ticket re-use, and
I was re-assured that ticket re-use was likely to going to work just fine...

   https://www.ietf.org/mail-archive/web/tls/current/threads.html#23035

TLS is a general-purpose protocol, used broadly beyond just the browser space.
With TLS in SMTP there's no demand or need for 0-RTT and server resources are
often more constrained than you'd find on a CDN server farm.  Repeat connections
are spaced further apart, and session lifetimes are longer (Postfix defaults to
an hour).

For Postfix, going back to a server-side session *increases* risk of loss of
forward secrecy, because bulky server-side session objections are written out
an on disk database, and e.g. with LMDB (a COW database) may take a long time
to be deleted.  By contrast session ticket encryption keys (STEKs) are small,
kept in memory, and are overrwritten and freed after ~2 hours.

Going back to server-side sessions would reduce resumption security for Postfix,
and would make servers more susceptible to DoS through cache exhaustion.

On the client side, non-reusable tickets would require substantially more complex
cache designs, and probably significant changes in the session APIs and internals
of TLS toolkits rather late in the evolution of the TLS 1.3 support code.

I am far from convinced that the effort would not be better spent improving STEK
key management in TLS server farms, which will need to support TLS 1.2 in parallel
with TLS 1.3 for quite a long time (likely a decade or more).

I believe that the proposed change is well intentioned but counter-productive.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 12:39:06 -0500

On Tue, May 02, 2017 at 01:33:37PM -0400, Viktor Dukhovni wrote:
> > I'll summarize the summary: Naturally the focus was on forward
> > secrecy and replay. On forward secrecy the main finding was that
> > it's not necessary to trade off Forward Secrecy and 0-RTT. A
> > single-use session cache can provide it, and with the modification
> > that ekr has created in https://github.com/tlswg/tls13-spec/pull/998
> > , such a cache works for both pre-auth and post-auth tickets, and it
> > allows clients to build up pools of meaningfully distinct tickets.

With existing APIs, dealing with "pools of meaningfully distinct
tickets" seems meaningfully non-trivial.

> > There's also an observation there that it should really be that
> > clients "MUST" use tickets only once. Any re-use likely discloses
> > the obfuscated ticket age, which is intended to be secret. Right now
> > it's a "SHOULD".

Why should ticket age disclosure be a problem?  How does ticket one-time
use not do the same?

> I was re-assured that ticket re-use was likely to going to work just

I sure hope so!!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 12:47:56 -0500

> Why should ticket age disclosure be a problem?  How does ticket one-time

Also, let's separate ticket re-use and 0-rtt.  The former is generally
desirable and workable.  The two might not be, but if so one should
expect a "SHOULD NOT" or "MUST NOT" to be specifically about the
combination of tickets and 0-rtt.  Also, the "SHOULD NOT" should have
guidance as to when/why one might do it anyways.  For many applications
the leakage in re-using tickets w/ 0-rtt will be a non-issue.

Nico
--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 10:48:29 -0700

> tickets" seems meaningfully non-trivial.

I would actually prefer if the client could request N tickets, but was
advised that this was too large a change to the protocol.

> Why should ticket age disclosure be a problem?  How does ticket one-time

The draft writes that it is to prevent connection correlation attacks.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 10:52:29 -0700

> I believe that the proposed change is well intentioned but

Note that the recommendation in the review is:

 'TLS1.3 should require that TLS implementions handling 0-RTT "MUST"
provide a mechanism to prevent duplicate tickets from being used for 0-RTT
data'

it is not quite about the general use of tickets - only as they pertain to
0-RTT data.  My understanding is that 0-RTT is not particularly interesting
for SMTP, so would that be ok?

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 13:00:50 -0500

> The draft writes that it is to prevent connection correlation attacks.

I would think that the ticket itself is enough for that when using
0-rtt.  I.e., if you don't want connection correlation to be possible,
you can't use 0-rtt.  The age business (which I hadn't looked into
before) seems incidental.

(Also, one would think that the client would send a timestamp in an
authenticator...  You know, a lot like what Kerberos does.)

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 May 2017 14:08:03 -0400

> On May 2, 2017, at 1:52 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> it is not quite about the general use of tickets - only as they pertain to 0-RTT data.  My understanding is that 0-RTT is not particularly interesting for SMTP, so would that be ok?

Yes, if the change is narrowly tailored to 0-RTT, *and* if server TLS stacks
don't stop supporting ticket reuse for "normal" (not 0-RTT) sessions, then
I have no direct concerns with changes that affect 0-RTT alone.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 11:15:06 -0700

> I have no direct concerns with changes that affect 0-RTT alone.

Great - I added a small errata comment on the github issue just recording
that too.

In that case, I only reason I see to stop using tickets multiple times is
to protect the obfuscated age. It reads to me like its purpose would just
be defeated. Is it really that hard for clients to use a 1-for-1
use-a-ticket-get-a-ticket approach?

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 13:16:53 -0500

On Tue, May 02, 2017 at 02:08:03PM -0400, Viktor Dukhovni wrote:
> > it is not quite about the general use of tickets - only as they
> > pertain to 0-RTT data.  My understanding is that 0-RTT is not
> > particularly interesting for SMTP, so would that be ok?
> 

In many environments (e.g., intra-corporate) the connection correlation
issue might not be a concern at all.  Though, of course, the default
should be (MUST) to assume that connection correlation is a concern.

So I would insist on the change being no stronger than "MUST NOT reuse
tickets with 0-rtt unless connection correlation is not an issue for the
application/user".

Nico
--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 11:17:42 -0700

On Tue, May 2, 2017 at 11:00 AM, Nico Williams <[email-masked]>
wrote:

> you can't use 0-rtt.

I don't think so. If the ticket is encrypted when it issued, I don't follow
how it could be used to correlate the original connection with the 0-RTT
connection.

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 13:25:30 -0500

> how it could be used to correlate the original connection with the 0-RTT

The ticket's _ciphertext_ is not visible to the eavesdropper when it is
issued, but it IS visible to the eavesdropper when it is used in 0-rtt.
The client cannot change the ticket's _ciphertext_.  Therefore the
eavesdropper can correlate 0-rtt connections when tickets are reused.
The obfuscated ticket age is irrelevant to that.

Now, I understand that the obfuscated ticket age goes in the clear in
0-rtt connections, and that if the attacker could work out the
unobfuscated time then the attacker could correlate not just the 0-rtt
ticket-reusing connections with each other, but also some earliere
ticket-establishing connection(s) observed at that time.

I find the obfuscated ticket age business a bit silly, but maybe I'm
missing something.  The client should really send an [encrypted]
authenticator that includes a timestamp, thus allowing the server to
detect replays and so on -- just like Kerberos.  Then this problem
wouldn't happen.

In any case, given that ticket-reusing 0-rtt connections can be
correlated with each other, the ability to further correlate them with a
ticket-issuing connection(s) established earlier doesn't seem to be that
much more of a big deal.

If it's at all possible to move this timestamp into an authenticator at
this point, I think that's the best solution.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 May 2017 14:31:10 -0400

> On May 2, 2017, at 2:15 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> In that case, I only reason I see to stop using tickets multiple times is to protect
> the obfuscated age. It reads to me like its purpose would just be defeated. Is it
> really that hard for clients to use a 1-for-1 use-a-ticket-get-a-ticket approach?

Yes, it is difficult to do 1-for-1.  In postfix there are parallel client processes
reading a shared session cache, and parallel writers updating that cache, and without
major changes to the code, when two writers update the cache back to back only one
ticket (really SSL_SESSION object) is saved.  Under load, many clients would not
find a ticket at all.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 May 2017 13:39:59 -0500

> this point, I think that's the best solution.

I thought TLS clients were supposed to have even worse clocks (in terms
of absolute time) than Kerberos clients.  The current ticket_age scheme
only requires the client's clock *rate* to be reasonable, not its
absolute time.

-Ben

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 11:42:01 -0700

> ticket (really SSL_SESSION object) is saved.  Under load, many clients

That makes sense to me. Thanks for the detail.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 11:45:27 -0700

On Tue, May 2, 2017 at 11:39 AM, Benjamin Kaduk <[email-masked]> wrote:

> I thought TLS clients were supposed to have even worse clocks (in terms of
> absolute time) than Kerberos clients.  The current ticket_age scheme only
> requires the client's clock *rate* to be reasonable, not its absolute time.
>

Here I have some data. Over 7 days of examining requests from low power
devices, 1 in 100 devices had a clock drift of at least 2 seconds. One in
1,000 had a drift of at least 43 seconds, and the worst offender had
drifted by years.

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 2 May 2017 21:46:03 +0300

> Why should ticket age disclosure be a problem?  How does ticket one-time

Ticket re-use is the reason why the masking uses add modulo 2^32 instead
of xor (which is more common).

Using add for masking does not leak identity of the parent session (xor
would leak it) even on re-use.

And ticket-reuse leaks the fact that the child sessions are related
anyway, nothing that can be done about that.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 May 2017 14:51:06 -0400

> On May 2, 2017, at 2:39 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> I thought TLS clients were supposed to have even worse clocks (in terms of absolute time) than Kerberos clients.  The current ticket_age scheme only requires the client's clock *rate* to be reasonable, not its absolute time.

Sure, and yet it might still have been better to transport the "obfuscated ticket age"
as an "encrypted ticket age", while keeping the elements of the design that expect only
a reasonable clock rate from the client.  Of course making such a change is likely
prohibitive at this time...

If the ticket is never re-used the "obfuscation" is perhaps sufficient, and if it
is re-used both obfuscation and encryption are defeated.  So obfuscation is perhaps
acceptable.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 May 2017 14:17:17 -0500

[replying to the part of your message I did not already cherry-pick and
reply to...]

> detect replays and so on -- just like Kerberos.  Then this problem

It's just to provide a little extra benefit on top of TLS 1.2 of
unlinkability in some situations.  In TLS 1.2, the session ticket was
sent unencrypted, so the ticket ciphertext is always available to the
attacker for correlation of ticket use to the original connection  (and
thus to other resumptions from that original connection).  With TLS 1.3,
the first time the observer sees the ticket ciphertext is when the
client uses it.  If the client only uses the ticket once, the naive
conclusion is that the resumption is not linkable to anything else --
the original connection or other resumptions from the same original
connection.  But, because we have this ticket age anti-replay mechanism,
the ticket age could be used to link resumptions from the original
session together, as described shortly.  This only matters when the
client has multiple tickets to use that were granted at the same
time/session, since if the client is reusing tickets then the ticket
ciphertext links the reuse, as you already noted.  So, if the ticket_age
was in the clear, then the attacker could subtract that to find when the
ticket was issued, and correlate the multiple tickets that were issued
together.  Obfuscating the ticket age prevents that correlation.

That correlation was unavoidable with TLS 1.2 tickets; if you're happy
with the 1.2 behavior, you don't need to care about reusing tickets or
how obfuscated your ticket age is.  (This is Viktor's postfix case, as I
understand it.)

> ticket-issuing connection(s) established earlier doesn't seem to be that

Agreed.  This whole anti-linkability thing is really in a very narrow
use case, and only when each ticket is used at most once.  (It's also a
very minor benefit, in my mind, compared to the other security
properties in scope.)

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 14:20:04 -0500

On Tue, May 02, 2017 at 02:17:17PM -0500, Benjamin Kaduk wrote:
> [ stuff about 1.2 elided ]

OK, sure, but why not avoid the problem in the first place in 1.3 by
sending an encrypted timestamp authenticator (sound familiar?).

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 May 2017 14:28:37 -0500

> sending an encrypted timestamp authenticator (sound familiar?).

If you mean an actual timestamp, see my previous reply about clock accuracy.

If you mean an encrypted relative time, well, that's what it is.  The
encryption is incredibly ad hoc, and requires that the key only be used
once, but the whole thing started by thinking of it as a super-janky
encryption scheme.  See
https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 14:31:46 -0500

> If you mean an actual timestamp, see my previous reply about clock accuracy.

Kerberos deas with that.

> https://www.ietf.org/mail-archive/web/tls/current/msg20373.html and nearby.

Yeah, it's an XOR with a one-time pad that... gets reused if you reuse
the ticket.  OF COURSE that fails.  Everyone knows not to reuse one-time
pads.

So, in 1.3, at least with 0-rtt, can we replaced this with a proper
encryption?

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 May 2017 14:41:34 -0500

> So, in 1.3, at least with 0-rtt, can we replaced this with a proper

If you reuse the ticket, the only concrete stated benefit from this
encryption is lost already.  What benefit would be gained from using
better encryption for ticket_age_add?

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 14:57:54 -0500

> better encryption for ticket_age_add?

Well, I did say that to me there's not much difference to _me_ between
"connections reusing the same ticket can be correlated to each other"
and "connections reusing the same ticket can be correlated to each other
and the connection whence the ticket".  Others might disagree, and if
that is reasonable enough then the best thing to do is to encrypt this
darned thing.

On principle, too, I think one might prefer to encrypt properly just
because we really shouldn't be doing this sort of thing.  Among other
things the lack of integrity protection for this field makes me think
that we need to analyze not only passive attacks against it, but active
attacks too.  It'd be so much easier if we didn't have to.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 02 May 2017 16:52:17 -0400

On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote:
> and the connection whence the ticket".  Others might disagree,

I disagree, Nico! :)

The difference here is between saying:

 * clients that want the latency benefit of session resumption can be
   careful to avoid ticket reuse and their connections will be
   unlinkable to a network observer who records session IDs.

versus:

 * clients that want the latency benefit of session resumption must
   accept that a network observer can trivially know that each
   connection is linkable to the previous one.

put another way: the difference between 0 required backlinks and 1
required backlink on each individual session resumption is the
difference (for a cautious yet session-resuming client) between 0
connections linked by a network observer and all connections linked by a
network observer.

TLS session linkability is relevant:

 * When a client is behind a NAT and wants their connections to be mixed
   with (indistinguishable from) other clients behind the same NAT, to
   the perspective of a network observer outside the NAT.

 * When a client moves network locations and doesn't want their network
   position to be trackable by a network observer.

 * When a client uses a VPN as an encrypted Internet proxy (or uses Tor
   or some other similar IP-anonymizing service), and does not want a
   network observer outside the VPN from being able to distinguish their
   traffic from the traffic of other users of the anonymity network.

        --dkg

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 14:04:07 -0700

>    connection is linkable to the previous one.

Agreed with your summary, but just a small note: clients might also want
forward secrecy which is why I was suggesting that clients be able to
request/enforce a STEK-less ticket.

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 16:29:54 -0500

> > and the connection whence the ticket".  Others might disagree,

Excellent.  So now consider what followed the above.  That is, that the
correct thing to do is to properly encrypt a timestamp rather than XOR
an OTP that then gets reused when the ticket gets reused.

Why on Earth are still doing improper crypto in TLS?!‽  In TLS 1.3 no
less!  Call it "janky", call it what you will.  It's broken.  Please
fix.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 May 2017 15:53:48 -0700

> an OTP that then gets reused when the ticket gets reused.

It's not XOR. It's addition mod 2^32. That's important because the
*difference*
between the ticket replay times is directly observable anyway.

-Ekr

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 18:02:59 -0500

> between the ticket replay times is directly observable anyway.

Computationally there's no real difference between that and XOR.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 May 2017 16:41:52 -0700

> Computationally there's no real difference between that and XOR.

What information do you believe you are gathering here?

As I stated, when the ticket is replayed, you already know the absolute time
difference between those replays.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 2 May 2017 23:49:31 +0000

Benjamin Kaduk <[email-masked]> writes:

>absolute time) than Kerberos clients.

Many of the devices I work with don't have clocks (at best they have non-
persistent monotonic counters), so I guess that's true in some sense...

Peter.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 17:28:39 -0700

> persistent monotonic counters), so I guess that's true in some sense...

This whole problem of needing client-side clocks, and having to obfuscate
an age, goes away if we remove the ticket age entirely.

Hopefully the security review makes a strong case that the age is fairly
useless from a security point of view. Even with the age, an attacker can
still generate millions to billions of replays. Even with very conservative
numbers, e.g. to just one host, the attacker can still certainly generate
tens of thousands of replays within the permitted window.  Better to
require servers to reject duplicates (when used with Zero-RTT), and leave
it at that.

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 May 2017 20:51:43 -0400

> On May 2, 2017, at 8:28 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> This whole problem of needing client-side clocks, and having to obfuscate an age, goes away if we remove the ticket age entirely. 
> 
> Hopefully the security review makes a strong case that the age is fairly useless from a security point of view. Even with the age, an attacker can still generate millions to billions of replays. Even with very conservative numbers, e.g. to just one host, the attacker can still certainly generate tens of thousands of replays within the permitted window.  Better to require servers to reject duplicates (when used with Zero-RTT), and leave it at that. 

Some choices are driven by practical engineering considerations.
The ticket lifetime is likely to be considerably longer than the
replay clock window.  The server should indeed reject replays,
but if it is able to flush the replay cache faster, it may be able
to handle that job a lot more efficiently under load.

What is a likely ticket lifetime for a server that supports 0-RTT
(let's assume an HTTP server)?  How wide a replay clock window is
likely reasonable (to allow for RTT and TCP retransmission delays)?

If the two are approximately the same, then just rejecting duplicates
and expired tickets is enough.  If the ticket lifetime is 10x or 100x
larger, it may make sense to be able to limit the lifetime of replay
cache entries to the smaller TCP skew.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 03 May 2017 01:45:42 +0000

On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni <[email-masked]>
wrote:

> .Some choices are driven by practical engineering considerations.

> to handle that job a lot more efficiently under load.

Good point! It's also common for caches to implement LRU, where a shorter
lifetime is better.

> (let's assume an HTTP server)?

I'm going to guess that providers will set it as high as they can ... every
little helps. So 7 days.

> How wide a replay clock window is likely reasonable (to allow for RTT and
> TCP retransmission delays)?
>

I think we have to assume that a replay attempt could come at any time. A
time based mitigation doesn't work.

-- 
Colm
-- 
Colm

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 2 May 2017 22:38:09 -0400

> I'm going to guess that providers will set it as high as they can ... every

It seems like this would follow the same policies for session
management and/or authentication and authorizations. If its low value
data (like a GMail account), then let it live longer, like weeks. If
its high value data (like executive compensation, mergers and
acquisitions or pending litigation), then its probably shorter, like
hours to days.

What's the polyfill that allows data sensitivity levels to trickle
down into the transport layer?

Jeff

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 May 2017 20:17:05 -0700

Colm,

Thanks for your review. Interesting stuff.

Scrolling ahead to the recommendations, I see you have:

* Require implementations to robustly prevent Ticket re-use for 0-RTT.

This seems like a good idea. I think it's arguable that we got a bit
nihilistic about this, and as you say, you can do a pretty good job of
reducing replay within a given data center using some local
anti-replay mechanism. I would tend to think that a strong SHOULD is
what you want here, as a MUST is going to be a lot more like a 6919
MUST (BUT WE KNOW YOU WON'T). I'll start preparing a PR on this.  Here
are the points I plan to make:

- There are a series of attacks involving lots of replays
  (cherry-picking your draft)

- Implementations cannot completely prevent replay but can do a lot to
  limit it using the following techniques (focusing on strike register
  and single-use cache).

I understand from your document and our previous conversation that you
believe single-use tokens are easier to implement on the server side,
but I'm not sure I really follow your argument. If you want to provide
some short text on that that we can all agree on, then I think we
could incorporate this as well.

* Partial mitigation for Gilmor attacks: deliberately duplicate 0-RTT
  data

This seems like some sort of extra-grease, but I'm kinda skeptical
that anyone is going to do it. Perhaps it would be useful to add it to
draft-ietf-tls-grease?

* Require TLS proxies to operate 0-RTT transitively

I've read this several times but I have to admit I don't understand
it. Do you think you could rephrase?

The following doesn't appear in your recommendations, but I think you
also think we should:

* Adopt something like PR#998 to make each PSK_id correspond to a
  different PSK even when they are issued on the same connection.

This seems straightforward, and I think we would also want to add some
text in security considerations describing the security implications
of the use of session-cache style PSKs to those of ticket-style PSKs,
especially when this technique is used.

* Require that clients only use tickets once.

For the reasons Viktor indicated, I tend to think this is inadvisable.
As you indicate, there are two implications of ticket reuse:

- It leaks some of ticket_age If the server wants to support it, it
- needs to not have a single-use session cache, so that threatens PFS.

As discussed on the list, the ticket_age issue is principally a
linkage issue, and the ticket is inherently linkable [0]. WRT the PFS
issue, the server can always implement a single-use cache if it wants
to, and if the server is doing ordinary tickets (which I understand
you don't like, but I don't think we are going to ban), then the PFS
situation seems unchanged. I have considered whether we should have a
way for the server to say "only use this ticket once" but I'm not sure
how that helps as the server can just unilaterally forget the tickeet.

* Remove ticket_age

This doesn't seem like a good idea: if you are implementing a strike
register, you want to use ticket_age to help distinguish "fresh" from
"unknown state". I.e., the ticket_age + the ticket issue time allows
you to determine approximately when a CH was sent, and any CH that
is significantly older or newer than now is forced back into 1-RTT.

-Ekr

[0] With that said, it wouldn't honestly be that hard to
Derive-Secret() a mask off of the PSK at the same time we derive the
early data key, if we really wanted to.

On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh <[email-masked]> wrote:

> https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for
> both pre-auth and post-auth tickets, and it allows clients to build up
> pools of meaningfully distinct tickets.
>
> Unfortunately, I wasn't aware until Friday that this review would be
> coming so late in the TLD1.3 draft process, and my apologies for that. I am
> now planning to attend the future WG in-person meetings and look forward to

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 May 2017 23:27:04 -0400

> On May 2, 2017, at 9:45 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> I think we have to assume that a replay attempt could come at any time.
> A time based mitigation doesn't work.

A time-based mitigation does not remove the need for an anti-replay
cache (where a service protocol, supports 0-RTT, but is not idempotent).

What I am saying, is that a time-based counter-measure can substantially
reduce the size of the required cache, because out-of-window replays
are rejected.  That replay window can be a narrow window around the time
the ticket is first (and never again legitimately) used, rather than the
much larger ticket validity interval.

The obfuscated_ticket_age field makes it possible to determine which
transmissions are "in-window".  It remains an exercise for the implementor
to handle "in-window" replays appropriately.

I agree with Nico that additive obfuscation feels like a hack, but am
willing to accept this as somewhat "natural" within the design tradition
of TLS.

Could someone explain how observing ticket reuse reveals the secret
"ticket_age_add" value?  The situation seems "time translation
invariant" under changes in the "ticket_age_add" value.  Doesn't the
attacker see the same result as he would see with a for an offset
"ticket_age_add" obtained at a corresponding offset time in the past?

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 23:21:51 -0500

> persistent monotonic counters), so I guess that's true in some sense...

Yeah, but a non-persistent clock is fine if the client can learn time
from the server (and keep a different offset from system time to every
server if need be, learning system time from one of them, or from NTP,
or whatever).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 23:22:28 -0500

> What information do you believe you are gathering here?

I believe the attack described is finding the time of the session's
establishment.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 23:24:36 -0500

> require servers to reject duplicates (when used with Zero-RTT), and leave

It's hard to disagree with this.  The only problem is that the caches
needed for server-side replay protection are non-trivial to implement,
especially with high concurrency, and even more so for clustered
services.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 May 2017 23:28:05 -0500

> cache (where a service protocol, supports 0-RTT, but is not idempotent).

Bingo.  There's no need for a replay cache for the 0 payload if it
represents an idempotent operation.

As long as the server can fall back on a full handshake, all is good.

> much larger ticket validity interval.

I don't believe replay cache size is that big a deal (though it's not
nothing).  The hard thing is concurrency.

> willing to accept this as somewhat "natural" within the design tradition

That is... a ringing endorsement of he obfuscation thing!  :)

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 May 2017 21:41:00 -0700

> I believe the attack described is finding the time of the session's

Hmm.... Can you walk me through how you think that works?

-Ekr

Nico

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 2 May 2017 22:32:50 -0700

> Thanks for your review. Interesting stuff.

Thanks too for taking the time to read it.

> MUST (BUT WE KNOW YOU WON'T).
>

A provider choosing to allow replays to their own applications is on them,
they can own the stack top to bottom, take the risk, have a response team
handle attack events, etc ... That's a legitimate case for "SHOULD", there
are exceptions to everything.

But at the same time, what I think we should care most about is the
interoperability case. So for example, if a TLS library, a web server, or
an upstream CDN, can break the assumptions of a down-stream service or
application, that's where we'll see CVEs cropping up. In those cases, I
think the problem is the upstream component, breaking long-held and fair
assumptions. In those cases, it feels like a "MUST".

I'm not sure how to strike a balance, so chose the more secure option.

> could incorporate this as well.

It's probably not important to get into a single-use token cache in the
draft itself. That was just intended for implementors. One thing that makes
a single-use cache slightly easier to implement is that reads and writes to
keys need not be sequenced relative to any kind of checkpoint.

With a strike register, some kind of checkpoint process is needed. A simple
one is to start with a clean slate, accept only writes for a time period
equivalent to the replay window, and then go read-write. But that kind of
modality is, I think, required. With a single-use cache, it need only
sequence the reads and writes to individual keys. Though it must store much
much more state, so there are different trade-offs to consider.

> that anyone is going to do it. Perhaps it would be useful to add it to

Grease is a good place for it for sure.

> it. Do you think you could rephrase?

What's in the draft is that there should be an application profile and that
TLS implementations should provide applications with special functions to
tell apart the early and regular data. The problem is that doesn't work
with TLS proxies (like CDNs) ... because the proxies are re-combulating the
data as a single stream to the origin. So the origin can't tell which data
was replayable.

If 0-RTT replay is tolerated, I think that's a big gnarly problem leading
to CVEs. If we prevent replay by other means, like the strike register,
it's not so big a deal.

What I was suggesting was that such proxies always send an outgoing 0-RTT
section to the origin that exactly lines up with the 0-RTT section that
came in on the front end. It's quite hard to make that all work; the CDN
would have to accept 0-RTT only if the origin also does. But I can't see
another way that really works, especially for Layer 4 accelerators. Again,
if 0-RTT replay is forbidden, not nearly as big a deal.

>   different PSK even when they are issued on the same connection.

Big +1 to this.

> For the reasons Viktor indicated, I tend to think this is inadvisable.

I've been thinking more about this. What if tickets are single-use when
used with 0-RTT, but otherwise allowed for multiple uses? If that's
acceptable, then could we drop the age from tickets purely used for
resumption. That way the age would only appear on tickets that are used
once.

I think that way we get everything.

* Remove ticket_age
> is significantly older or newer than now is forced back into 1-RTT.

Yep, I was wrong about this, I get it now, and that makes sense.

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 May 2017 17:03:01 +1000

On 3 May 2017 at 15:32, Colm MacCárthaigh <[email-masked]> wrote:
> I've been thinking more about this. What if tickets are single-use when used
> with 0-RTT, but otherwise allowed for multiple uses? If that's acceptable,
> then could we drop the age from tickets purely used for resumption. That way
> the age would only appear on tickets that are used once.

I could see the way to moving the ticket age to the early_data
extension.  It saves a few bytes in an uncommon case, complicates a
bit of the design, but otherwise isn't overly disruptive.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 3 May 2017 11:15:03 +0200

Hi Colm,

thanks for your review.

I disagree with your assessment in a few places.

First, talk about tickets and point out that distributing the session
key for encrypting the ticket content (Session Ticket Encryption Keys
(STEKs)) is a challenge and raises security concerns. You point to
Akamai CDN and their huge number of hosts.

The TLS 1.3 ticket concept combines three types of tickets approaches
standardized for earlier versions of TLS, namely session resumption
(which caches keys on both sides), and RFC 5077, which allows you to use
self-contained tokens aka tickets in the style of Kerberos tickets.
Finally, you could use RFC 5077 with references to tickets but you loose
the stateless nature (since you have to write keys, and other necessary
parameters in a database).

Which approach is best depends on your infrastructure.

When you use TLS in your environment you need to make a few decisions
about the algorithms you want to support, key lengths, etc. You also
have to determine what ticket concept you want. Maybe the right decision
for a deployment that has to synchronize STEKs across so many hosts
isn't a great idea.

Second, you talk about 0-RTT and replay attacks. In a 0-RTT exchange you
cannot rely on the nonce exchange for replay protection (as it was done
in earlier TLS versions). Instead, you have to rely on other replay
protection mechanisms, and taking the application semantic into account
is obvious approach. Clearly 0-RTT is not applicable to all environments
and hence the spec contains a warning: "Protocols MUST NOT use 0-RTT
data without a profile that defines its use."

What I could, however, imagine is to add either in the TLS handshake or
at the application layer something like a timestamp or a sequence number
so that the server-side can check for replays. This is what has been
done with other security protocols in the past. Is the TLS layer the
right place or the application layer? Hard to say.

Minor issues:

You also suggest that 0-RTT supports PFS. The definition of PFS
unfortunately is not super helpful here when there are so many keys in
play. The PFS definition talks about the loss of the long-term key. What
you care about is the potential loss of the STEKs, which is not a
long-term key.

You write: "Any client that attempts to use a ticket multiple times will
also likely leak the obfuscated_ticket_age value, which is intended to
be secret." The obfuscated_ticket_age is not secret - it is sent in the
clear. What is supposed to be kept confidential is the ticket age. I
have been wondering myself what the privacy value of the
obfuscated_ticket_age, and the ticket age is and I am still not
convinced that it provides much benefit.

Ciao
Hannes

PS: You talk about OATH in this paragraph:

"
To avoid simple spoofing risks, many such systems perform throttling
post-authentication. For example the request may be signed
cryptographically (see the AWS SIGv4 signing protocol or the OATH
signing process), that signature is verified prior to throttling. This
post-authentication property is one reason why such protocols are
designed to be extremely fast to verify, which often means as much
cryptography as possible must be pre-computed, making random nonces
infeasible in many cases.
"

What you actually mean is OAuth (OATH is a different effort also related
to earlier IETF work on one-time-passwords). Your reference points to an
old OAuth specification that has been replaced by OAuth 2.0, which does
not use the same application layer signing anymore.

On 05/02/2017 04:44 PM, Colm MacCárthaigh wrote:
> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in
> s2n. Thanks to feedback in the room I've now tightened up the findings
> from the review and posted them as an issue on the draft GitHub repo:
> 
> I'll summarize the summary: Naturally the focus was on forward secrecy
> and replay. On forward secrecy the main finding was that it's not
> necessary to trade off Forward Secrecy and 0-RTT. A single-use session
> cache can provide it, and with the modification that ekr has created
> in https://github.com/tlswg/tls13-spec/pull/998
> <https://github.com/tlswg/tls13-spec/pull/998> , such a cache works for
> secure, and the review includes 5 different attacks against 0-RTT data
> to illustrate that. Attacks 1 and 2 show that the kind of replay
> permitted by the draft is very different from the kind of replay
> permitted by dkg's existing downgrade-and-retry attack. I also go over
> why it very very difficult to many applications to achieve that
> idempotency, and why one idempotency pattern actually relies on
> non-replayable messages. 
> 
> Attack 3 shows that idempotency is not sufficient, applications must
> also be free of measurable side-effects, which is not practical.  Attack
> 4 shows that 0-RTT breaks a common security mechanism:
> spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability
> enables an additional form of traffic analysis. 
> 
> coming so late in the TLD1.3 draft process, and my apologies for that. I
> am now planning to attend the future WG in-person meetings and look
> forward to seeing many of you there. 
> 
> -- 
> Colm
> 
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 05:45:16 -0700

On Wed, May 3, 2017 at 2:15 AM, Hannes Tschofenig <[email-masked]
> Akamai CDN and their huge number of hosts.

I used Akamai as a reference as they are probably the worlds largest
deployment of TLS, measured by hosts. But to be clear; Akamai has always
done great work on securing keys and I know it's something they take very
seriously.

> Which approach is best depends on your infrastructure.

Here I want to be more opinionated than that. I think that forward secrecy
is important and is more secure, and should always be provided. Its absence
is a security issue, so it's appropriate to highly in a security review.
It's possible in all cases, as shown, and the trade-off is unnecessary from
first principles.

The fundamental problem with STEKs is that there is no forward secrecy, and
in the case of TLS1.3, no FS for critical data. It's an unfortunate
alignment, as it really undoes a lot of the collective good work to deploy
PFS in practice.

Deploying the PFS cipher suites took nudging providers along; and was not
without cost. I think the same thing may happen with STEKs in the
not-too-distant future. People seem to care about getting forward secrecy.
Smart customers with particularly sensitive workloads will insist.

> right place or the application layer? Hard to say.

This is easy to say; the TLS layer is the right place. It is not practical
for applications to defend themselves, especially from timing attacks.

> you care about is the potential loss of the STEKs, which is not a

As the crypto-shortcuts paper showed, in some cases servers had STEKs in
place for the duration of the experiment (months) and perhaps years.

> convinced that it provides much benefit.

Sorry, you're right, it's the ticket_age_add which should remain secret. My
understanding is that as NewSesstionTickets messages occur post-handshake,
that they are encrypted under the session keys, and that value is secret.

> not use the same application layer signing anymore.

Thanks for letting me know!

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 09:07:16 -0400

> On May 3, 2017, at 8:45 AM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> The fundamental problem with STEKs is that there is no forward secrecy

Sorry, STEKs are not long-term keys.  So it makes little sense to claim
that use of STEKs breaks forward secrecy.  Indeed STEKs may be more safe
than server-side storage of complete sessions, since the latter are much
more likely to end up on disk.

It is a shared meme that session tickets break forward secrecy, but it is
not correct.  Poorly implemented session ticket keys can be a problem, but
so can poorly implemented session caches.

The distributed single-use caches you are imagining are very complex beasts,
and I am much less inclined to trust those than a comparatively simple key
rollover system (just three keys need to be known at any time, the past key
for as yet unexpired sessions, the current key used to mint and decrypt
new sessions and the future key created shortly before the current key becomes
the past key, giving enough time for all the cluster nodes to get a copy).

The time window for session compromise is never zero, after all, the keys
are in memory while the connection is active.  It is unwise to insist that
forward-secrecy is broken if session keys are not destroyed instantaneously
at session closure.  A reasonably short non-zero window of exposure may yield
greater security benefit than a design which appears to be more secure by
attempting synchronous destruction of keys at much greater overall design
complexity.

-- 
-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 08:22:00 -0700

On Wed, May 3, 2017 at 6:07 AM, Viktor Dukhovni <[email-masked]>
wrote:
> Sorry, STEKs are not long-term keys.

There's nothing enforcing that, and research has shown STEKs being used for
long periods of time.

I think if we ask the question "What is probably the weakest security point
in all of TLS?" I would give STEKs a strong nomination. Some problems;

* STEKs can be used for years at a time
* STEKs can be used across many domains and certificates
* STEKs are often stored unencrypted on disk, hardcoded in configs
* No mechanism to enforce how tickets are encrypted. Could be RC4. Most
likely is AES, which mode?
* Tickets are replay-able, weakening the protections against side channels.
Most common algorithm is not side-channel resistant.

They just seem to undo a lot of the good work we do in moving TLS endpoints
to better algorithms and security modes.

> So it makes little sense to claim that use of STEKs breaks forward
> secrecy.

I don't think this is even a controversial claim; the draft itself
describes it. STEKs do break forward secrecy.

> Indeed STEKs may be more safe

STEKs often go in config .. which is usually on dist. Caches are most often
in-memory only.

> so can poorly implemented session caches.

That's true about caches, but one of the points in the review is that the
economics work a little different and may favor security.

>
> The distributed single-use caches you are imagining are very complex beasts
>

My bias here is that I work on distributed systems, but a single-key
distributed hash table is one of the simplest things we build. Though I
acknowledge that it takes good attention to detail to properly secure
access, and the data.

> the past key, giving enough time for all the cluster nodes to get a copy).

You can take a hybrid approach where you use such keys to encrypt the data
in the cache itself. I think that gives you the "good" combined security
properties of both.

> at session closure.

Others argue for something even stronger than this: that the keys should be
ratcheted/rekeyed even while the session is still in use, to provide some
forward secrecy for prior data on a connection that is still active. This
is the general direction of best practice.

>   A reasonably short non-zero window of exposure may yield

Yep, that is true.

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 May 2017 15:31:00 +0000

FWIW, I agree with Colm about STEK’s being TLS 1.3’s weakest point, for the reasons he lists.  The security properties are very different from the full-handshake TLS 1.3, and that is why OpenSSL treats “early data” as a completely separate thing from the “normal stream.”

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 11:55:45 -0400

> On May 3, 2017, at 11:22 AM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> There's nothing enforcing that, and research has shown STEKs being used for long periods of time.

That's an implementation defect.  Not a problem with STEKs as such.

In Postfix STEK lifetime == 2 * session lifetime (the latter defaults to 1 hour).

Some time this year I'll introduce key rotation by default into OpenSSL, which
will result in short-term STEKs for all applications that don't implement session
ticket key management callbacks.  That way, it is not just applications that take
the time to handle key rotation that will get short-term STEKs. 

Mind you, long-lived servers such as Apache, Nginx, ... should also implement
key rotation via the relevant callback mechanisms and should not use static
keys.  Sloppy implementations are not a problem with STEKs, the same sloppy
implementations will just as likely have insecure caches.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 May 2017 16:01:46 +0000

> Some time this year I'll introduce key rotation by default into OpenSSL, which

Great :)

> use static keys.  Sloppy implementations are not a problem with STEKs, the
> same sloppy implementations will just as likely have insecure caches.

The protocol design should avoid setting traps for the unwary.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 12:10:12 -0400

> On May 3, 2017, at 12:01 PM, Salz, Rich <[email-masked]> wrote:
> 

No, that responsibility falls on libraries.  STEKs are not a trap for the
unweary.  Libraries that support static session tickets by default can be
viewed as such a trap.  So the onus to fix this is on us (OpenSSL team)
not the TLS protocol.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 May 2017 16:15:14 +0000

> No, that responsibility falls on libraries.  STEKs are not a trap for the unweary.

Unweary :)  Funny.

We disagree.  And I think the concerns Colm has raised show that others are also in agreement.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 May 2017 13:16:45 -0500

> Hmm.... Can you walk me through how you think that works?

Well, I hadn't done it myself.  I see now though that the attack doesn't
work.

I would still prefer proper encryption.  But this works.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 14:20:58 -0400

> On May 3, 2017, at 12:15 PM, Salz, Rich <[email-masked]> wrote:
> 

I see all the talk of STEKs (session ticket encryption keys) breaking forward-secrecy as FUD.
All kinds of poor implementation and/or operational practices may compromise confidentiality,
The (mis)use of long-term STEKs is not particularly special among such practices.

If libraries implement "long-term" STEKs, that's a library bug, not a protocol issue.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 May 2017 13:29:56 -0500

> viewed as such a trap.  So the onus to fix this is on us (OpenSSL team)

A big +1 to this.

I think it would terrible if we couldn't have resumption at all because
one common implementation mishandles old key deletion.

Nico
--

---

From: Timothy Jackson <[email-masked]>
Date: Wed, 3 May 2017 18:33:33 +0000

>    The (mis)use of long-term STEKs is not particularly special among such practices.

This may be true, but that still doesn’t make it a good idea. We should probably do *something* about this. J

>    If libraries implement "long-term" STEKs, that's a library bug, not a protocol issue.

Seems to me that both points are valid and not mutually exclusive. Why don’t we capture this discussion in the RFC itself? We often provide guidance/alerts for implementers. Why should this be different? Such a warning would presumably prevent it from being a trap for the unwary (or unweary, depending on how much rest they’ve gotten) without requiring a change to the protocol itself. 

We could even go so far as to add a “SHOULD NOT” around using STEKs that are long-lived? That would provide a strong hint to implementers but leave flexibility for those who need different behavior and understand the risks?

Cheers,

Tim
—
Tim Jackson | Product Security Architect | MobileIron, Inc.

On 5/3/17, 11:29 AM, "Nico Williams" <[email-masked]> wrote:

    A big +1 to this.

    Nico
    --

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 14:54:50 -0400

> On May 3, 2017, at 2:33 PM, Timothy Jackson <[email-masked]> wrote:
> 
> We could even go so far as to add a “SHOULD NOT” around using STEKs that are long-lived?

No specific objection there, motherhood and apple pie... so long as we don't go too
far and say "SHOULD NOT" to STEKs broadly.  They are a sensible way to handle session
caching, in combination a sensibly implemented key rotation approach.  One also SHOULD
NOT store long-term copies of sessions, deploy world-readable private keys, ...

So, if folks feel that it is necessary to give such advice, that's fine.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 12:19:30 -0700

> one common implementation mishandles old key deletion.

With the improvements in 1.3 all of this FS only pertains to 0-RTT data,
not resumption in general. One solution would be to have two, or three
sub-types of ticket exchanges:

Type 1 - same as now, except remove the ticket age, generally intended for
resumption. Can be used multiple times.

Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (maybe
not in the ticket itself, but somewhere in the handshake), can only be used
once.

Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to
prevent self-encryption.

Though honestly, I'm not even sure 2.2 is a great idea any more, maybe too
much complexity, and we can just measure the size and enforce things that
way.

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 May 2017 14:35:17 -0500

> resumption. Can be used multiple times.

No, please don't remove the obfuscated ticket age.  Either make it
encrypted or leave it as-is.

> not in the ticket itself, but somewhere in the handshake), can only be used

No.  Give advice.  Do not remove these features.

> Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to

I don't grok this.

Nico
--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 13:19:35 -0700

> encrypted or leave it as-is.

If it is to be encrypted, say AEAD'd, it needs to be encrypted under a key
that the client and server share; because the client needs to modify the
age before sending. Moving the age to its own message, post Client-Hello,
could solve that - so it comes out of the ticket.

That scheme is a bit weird and circular: the server would have to "use" the
ticket to derive a key that decrypts the age, to then decide if it should
"really use" the ticket for 0-RTT data. That seems pretty convoluted to me
- could be a fairly complicated security proof.

> No.  Give advice.  Do not remove these features.

I think the can only be used once for 0-RTT needs to be firm. Otherwise
0-RTT mode is insecure.

> > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to

Self-encrypting tickets require STEKs and all of their problems. A client
could say "Don't send me a STEK-based ticket", and this can be enforced by
requiring those tickets to be smaller than the RPSK in size.  The client at
least knows that the ticket couldn't possibly have been self-encrypted.
Though obviously it says nothing about how good a job the server is doing
of keeping the keys secret.

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 16:20:11 -0400

> On May 3, 2017, at 3:19 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to prevent self-encryption. 

The kind of application whose security requirements preclude use of RFC 5077
session tickets can and should likely also avoid both 0-RTT and session
resumption entirely.  Otherwise, allow the server to choose a sensible session
management approach.

Second-guessing the server's design by looking at ticket sizes seems rather
contrived.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 13:27:11 -0700

On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <[email-masked]>
wrote:

> resumption entirely.

I don't agree with this. Why should users of mobile devices, to pick one
example, have to choose between speed and the extra risk of data disclosure
for their requests and passwords?

> contrived.

It's not a second guess. If the ticket size is smaller than the RPSK, then
it provably can not have been self-encrypted. But I agree that it says
nothing about the server-side security. They might be posting the keys to
twitter.

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 May 2017 16:20:48 -0500

> could solve that - so it comes out of the ticket.

Naturally.  That's why we have ticket session keys.

> - could be a fairly complicated security proof.

It's what Kerberos has been doing for decades.  RFC4120 (before that
RFC1510).

> I think the can only be used once for 0-RTT needs to be firm. Otherwise

I don't agree: the application may not care.

> Self-encrypting tickets require STEKs and all of their problems. [...]

Can you elaborate?  (I don't follow TLS WG that closely.  I'm from
KITTEN WG.)

Nico
--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 14:26:49 -0700

> It's what Kerberos has been doing for decades.  RFC4120 (before that

I'll take your word for it!

> > > > not in the ticket itself, but somewhere in the handshake), can only
> be
> > > used
> > > > once.
> > >

No, it's still insecure ... because it may matter to the application, and
worse still the application owner may not even realize that. The existence
of some rare environments where one can truly, deeply, understand the
idempotency and side-effect problems and fully reason about their
implications does not invalidate that. For security, we must assume the
worst, not hope for the best.

Also: rejecting duplicates is safe in both environments. The main downside
is the cost to operators, but I'm not sympathetic to an argument that costs
should be cut by pushing significant risk downstream.

> Can you elaborate?  (I don't follow TLS WG that closely.  I'm from

Sure ... https://www.ietf.org/mail-archive/web/tls/current/msg23100.html

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 18:04:45 -0400

On May 3, 2017, at 4:27 PM, Colm MacCárthaigh <[email-masked]> wrote:

> On Wed, May 3, 2017 at 1:20 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> I don't agree with this. Why should users of mobile devices, to pick one example,
> have to choose between speed and the extra risk of data disclosure for their requests
> and passwords?

Their security requirements don't preclude use of RFC 5077 session tickets,
they've been using them all along, and will continue to do so for the majority
of destinations that will take quite some time to upgrade to TLS 1.3.

As you might recall, I don't agree that STEKs are fundamentally less secure
than remote session caches, I rather suspect that sensibly implemented STEKs
are safer.

[ I do concede that the current OpenSSL implementation leaves too much of the
responsibility of doing STEKs right to applications, and I will endeavour to
fix that.  It is not especially difficult to implement a default-on key rotation
mechanism. ]

> It's not a second guess. If the ticket size is smaller than the RPSK, then it
> provably can not have been self-encrypted. But I agree that it says nothing
> about the server-side security. They might be posting the keys to twitter.

As you yourself concede it is not the size that matters.  It is a very marginal
indication of the security of the remote session.  The server may wish to decorate
the session id with additional data (say which data-centre issued the session)
and fail your test, and yet be doing the type of session caching you're asking
for.  The client should either trust the server to cache sessions correctly (this
would be the default client behaviour in most cases), or it can choose to forgo
session re-use.

Feel free to malign bad implementations of STEKs, but the basic mechanism is
sound.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 15:29:16 -0700

On Wed, May 3, 2017 at 3:04 PM, Viktor Dukhovni <[email-masked]>
wrote:

> example,

I'm not sure how any of that is relevant. Mobile users, like everyone else,
appreciate speed; they'll want to use 0-RTT. I'm sure they also appreciate
their data being less at risk, so forward secrecy is good for them too. I'm
saying they should be able to get both. Again, you can combine the security
properties of a STEK with a cache if you want, by encrypting the cache
entries the same way you would use a STEK.

> fix that.  It is not especially difficult to implement a default-on key

Just an aside related to that; it can be useful to fuzz ticket lifetimes a
bit so all of the tickets from a STEK don't expire at exactly the same
time. That can lead to a lot of painful renegotiations happening at once.

> As you yourself concede it is not the size that matters. It is a very
> marginal indication of the security of the remote session. The server may
> wish to decorate

the session id with additional data (say which data-centre issued the
> session)

True.

> Feel free to malign bad implementations of STEKs, but the basic mechanism

"sound" goes too far. Pervasive forward secrecy is one of the central
security goals of modern cryptography, some schemes go so far as to bake in
very frequent key agreement and ratcheting. STEKs aren't compatible with
this goal. They may be acceptable operationally today, but I think they
must be borrowed time if the central goal is meaningful.

-- 
Colm

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 08:56:05 +1000

> for applications to defend themselves, especially from timing attacks.

If you care about these attacks as much as it appears, then you can't
reasonably take this position.  We've historically done a lot to
secure applications at a single point, and we're almost at the end of
what we can reasonably do for them at this layer.  We need to think
more hollistically and acknowledge that applications need to take some
responsibility for their own security.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 16:16:49 -0700

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson <[email-masked]>
wrote:

> reasonably take this position.

An analogy may help here. TLS has always offered anti-replay, it is one of
our core security guarantees, and the assumption that it is there is subtly
baked in to many applications.

Suppose we wanted to remove a different security guarantee: integrity
protection/tamper-proofing. Suppose we decided to offer a fast "No MAC"
mode for streamed uploads, it is faster, more stream-y (no need to wait for
each record to be complete), and TLS is really mostly about secrecy. But to
be "safe" we decide that it's only on optionally and sometimes, and we
always have to tell the application which data may have been tampered with.

The application can use its own MACing, or FECing, or whatever, and really
it should have been doing this from the days of plaintext HTTP, right!?
It's all the application's responsibility - we say, they can deal with it
[*]

Except MACing is hard, and they run in to Lucky13 all over again, or just
use MD5 because they don't know any better, and so on.  Or worst of all: a
middle box decides to enable it on the front-end, with no knowledge to the
backend about what's happening.

In my view, this arrangement would plainly be crazy. We wouldn't consider
it. Instead, we provide protection for them using layering principles, and
TLS provides protections that TLS experts are good at.

And yet we do consider all of this for replay. I think it's because
collectively we haven't seen just how hard a problem idempotency and
application-level side-effects are and we are less familiar with the risks.
In the review, I've included 5 real attacks to illustrate that problems are
real. Several of them I can't see how to mitigate them at application
level, and I've been checking with experts on distributed systems. How
would you mitigate the throttling problem (attack 3) or the timing problem
(attack 4) on say a JVM object cache?

> We've historically done a lot to

No we don't. Servers can prevent replay.

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 19:26:23 -0400

> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> bit so all of the tickets from a STEK don't expire at exactly the same time.
> That can lead to a lot of painful renegotiations happening at once.

More than "a bit".  In Postfix session tickets have a constant lifetime regardless
of whether they were issued at the beginning of end of the current STEKs duration
is the STEK encryption key.  This works, because each STEK is retained as a
decryption-only key for a second "lifetime" while the next key is employed to
encrypt (and decrypt) new sessions.

There is no clustering of session expirations.  The plan is to do the same in
the default-on key rotation for OpenSSL.

-- 
	Viktor.

---

From: Bill Cox <[email-masked]>
Date: Wed, 3 May 2017 17:19:41 -0700

> No we don't. Servers can prevent replay.

Replay prevention looks straight forward with a server-side cache.  This
may not work well for the top 1,000 web sites, but I bet it will work well
for the bottom 1 billion sites.  Personally I think the important thing is
for popular HTTP server software to implement replay protection for TLS 1.3
0-RTT by default.  Admins at literally millions of small companies are
going to want to enable this new 0-RTT hotness.  That part should be made
easy - say one line in a config.  Enabling 0-RTT without replay protection
should be harder.

Bill

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 10:25:35 +1000

> No we don't. Servers can prevent replay.

I was responding to an overly broad statement you made.  In the
discussion you also talk about timing side-channels and other ways in
which information can leak.  Nothing we do at the TLS layer will
prevent those from being created in applications.

Also, it might pay to remember that this is part of a larger context.
Applications routinely retry and replay; if they didn't, users would.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 17:50:34 -0700

> prevent those from being created in applications.

Sure, but things we're doing at the TLS layer can make it  much worse, as
in this case. I don't think we can make attacks easier.

> Applications routinely retry and replay; if they didn't, users would.

In the larger context, not all HTTP calls are coming from user actions, or
from clients that retry in that way. Some clients need to be careful,
precisely to achieve idempotency or safety. The review details the reasons
why, and also why it is impractical for actors to separate out these cases
and simple "not use" 0-RTT, due to how layers work and systems
interoperate.

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 20:51:37 -0400

> Pervasive forward secrecy is one of the central security goals of modern
> cryptography,

Sure, given a sensible definition of forward-secrecy.  And near instanenous
deletion of session keys is not part of such a definition.

> STEKs aren't compatible with this goal. They may be acceptable operationally
> today, but I think they must be borrowed time if the central goal is meaningful.

We need to recall what thread-model is behind the desire for forward-secrecy.
It is I think not controversial to say that forward is concerned with limiting
the damage from end-point (especially server end-point) compromise, in which
confidentiality of long-term keys (still held on the endpoint) is lost.

Consider the fact that such compromise is unlikely to be detected and remediated
instantaneously.  Indeed not only will the adversary have access for some time
to sessions initiated post-compromise, he will also be able to impersonate the
real server after the server is "secured" because certificate revocation will
take days (or until the certificate expires) to take effect and more sessions
can be compromised via MiTM attacks after the keys stolen.

The incremental exposure of some fraction of a hour of sessions shortly before
compromise pales in comparison with the much longer post-compromise exposure
before the service is again secure.

STEKs are simpler to design and secure than a complex session cache. This
simplicity has security benefits.  Properly implemented STEKS have a lifetime
that is much shorter than any plausible compromise exposure time window.  Given
this, it makes sense to not consider potential STEK compromise as loss of forward
secrecy.

Forward secrecy guards against disclosure of truly long-term key material, with
a lifetime of weeks to years.  Once we get down to hours or minutes, it is quite
sensible to take a coarser view of time, with similar exposure for sessions
"just before" and "just after" compromise.

Maximally sensitive traffic can take the penalty of avoiding session caching
of any kind.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 18:03:23 -0700

> deletion of session keys is not part of such a definition.

I want to re-run DH for every bit transferred! of course I'm kidding, and
take your point. There's a balance to strike.

> confidentiality of long-term keys (still held on the endpoint) is lost.

In the case of STEKs, the key may also be compromised without compromising
the endpoint. With multiple endpoints, there is usually some kind of
central STEK distribution system to synchronize the keys. And they key may
also be compromised due to weak crypto on the tickets themselves. So we
have to add those too to the threat model. But caches have similar
challenges, which might even be harder.

> Maximally sensitive traffic can take the penalty of avoiding session

That does all makes sense, it just hasn't really been how TLS is deployed.

-- 
Colm

---

From: Watson Ladd <[email-masked]>
Date: Wed, 3 May 2017 18:11:36 -0700

> responsibility for their own security.

Historically TLS protected against replay attacks. Now it doesn't. An
application that relies on this property which TLS used to guarantee
is now broken. Clearly we could have provided it, we just chose not
to.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 May 2017 11:15:16 +1000

> is now broken. Clearly we could have provided it, we just chose not

Let's get the fallacy out of the way.  TLS 1.3 provides protection
against replay attacks, just not if you decide to use 0-RTT.

I realize that there is a real risk that this distinction will be lost
on some, but I can fairly confidently say that it isn't lost on those
who are considering its use in various protocols.  For instance, I've
spoken to someone who is looking at XMPP seriously and the advice
there is pretty close to *don't* use 0-RTT.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 21:19:20 -0400

> On May 3, 2017, at 9:15 PM, Martin Thomson <[email-masked]> wrote:
> 

Amen.

> there is pretty close to *don't* use 0-RTT.

One obvious use case for 0-RTT is DNS queries.  The query protocol is
idempotent, and latency matters.  So for DNS over TLS, 0-RTT would be
a good fit.   TLS session caches are not attractive on the DNS server
given the enormous query volumes, but STEKs would be a good fit.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 May 2017 01:31:02 +0000

> Let's get the fallacy out of the way.  TLS 1.3 provides protection against replay
> attacks, just not if you decide to use 0-RTT.
> 
> I realize that there is a real risk that this distinction will be lost on some, but I
> can fairly confidently say that it isn't lost on those who are considering its use
> in various protocols.

Well, for example, Chrome/boringSSL should arguably know better but are treating it all as one equivalent stream.

Is FF/NSS doing the same thing?

Why?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 18:39:13 -0700

> given the enormous query volumes, but STEKs would be a good fit.

As it happens, DNS queries are not idempotent.  Queries have side-effects,
for example Bind9 will rotate an RRset by one increment on each query.
Many providers charge by the DNS query. Many providers throttle DNS queries
(and TLS is intended as a mechanism to help prevent the ordinary spoof
ability of DNS queries).

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 18:41:05 -0700

> is now broken. Clearly we could have provided it, we just chose not

And that choice is insecure. If it's to be kept, I'd suggest renaming the
protocol.

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 May 2017 21:59:47 -0400

> On May 3, 2017, at 9:39 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 

This is sufficiently misleading to be false.

> for example Bind9 will rotate an RRset by one increment on each query.

Regardless of who the client is, the "attacker" can rotate the RRset
order by making his own query, no need to impersonate some other client.
And of course randomization of RRs in an RRset is normal.  Some clients
further randomize or re-order the results.

> Many providers charge by the DNS query.

They don't charge the client, which remains unauthenticated.  Hosted
DNS domains may be charged by query volume, but again the attacker
can make his own queries without replaying traffic from some other
client.

> Many providers throttle DNS queries (and TLS is intended as a mechanism
> to help prevent the ordinary spoof ability of DNS queries).

Again the client is unauthenticated, throttling is by IP address, there's
no need to repeat the same payload, indeed that's less effective since
throttling is biased towards queries for non-existent names, ...

Throttling is mostly for UDP, for lack of BCP-38 implementation.  DNS
over TLS *is* a good candidate for 0-RTT.  [ I would have chosen a more
simple protocol for DNS security than TLS, but given that DNS over TLS
seems to be moving forward, 0-RTT makes sense. ]

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 19:15:52 -0700

> This is sufficiently misleading to be false.

What I'm trying to get at is that idempotency is hard. Even the simplest
things that seem idempotent often are not. It's really really hard to do a
deep review. And that's if people even know to perform the review.

,<Your next two points are good, just cut for length>

> throttling is biased towards queries for non-existent names, ...

It's not always by IP address. Anti-DDOS is much more nuanced in my
experience, often take the QNAME into account.

> seems to be moving forward, 0-RTT makes sense. ]

+1 to that too!

-- 
Colm

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 4 May 2017 02:33:02 +0000

Chose not to provide replay protection?! I have to agree with Colm - it doesn't sound good. 

Care to justify?

P.S. Care to name (another :) one security-related protocol that doesn't provide replay protection?

Regards,
Uri

Sent from my iPhone

> On May 3, 2017, at 21:42, Colm MacCárthaigh <[email-masked]> wrote:
> 
> 
> 
> And that choice is insecure. If it's to be kept, I'd suggest renaming the protocol. 
> 
> -- 
> Colm

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 May 2017 20:13:20 -0700

[Deliberately responding to the OP rather than to anyone in particular]

Hi folks,

I'm seeing a lot of back and forth about general philosophy and the
wisdom of 0-RTT but I think it would be useful if we focused on what
changes, if any, we need to make to the draft.

I made some proposals yesterday
(https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).

Specifically:
1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
both session-cache and strike register styles and the merits of each.

2. Document 0-RTT greasing in draft-ietf-tls-grease

3. Adopt PR#448 (or some variant) so that session-id style implementations
provide PFS.

4. I would add to this that we recommend that proxy/CDN implementations
signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
Colm's original message).

Based on Colm's response, I think these largely hits the points he made
in his original message.

There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
What would be most helpful to me as Editor would be if people could review
these PRs and/or suggest other specific changes that we should make
to the document.

Thanks,
-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 4 May 2017 03:15:18 +0000

Nico Williams <[email-masked]> writes:

>Yeah, but a non-persistent clock is fine if the client can learn time from
>the server (and keep a different offset from system time to every server if
>need be, learning system time from one of them, or from NTP, or whatever).

In many cases neither the server nor the client have clocks.  They also don't
have much provision for keeping track of persistent state across devices.

Overall though it's a bit of a moot point because it's unlikely these devices
will ever do TLS 1.3 (it's going to be enough of a pain eventually moving them
to 1.2), I was just pointing out that you can't assume the presence of a
clock.  It may be perfectly OK to assume that anything that'll ever do 1.3
also has an accurate(ish) time source available.

Peter.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 3 May 2017 20:20:02 -0700

> Colm's original message).

This all sounds great to me. I'm not sure that we need (4.) if we have
(1.).  I think with (1.) - recombobulating to a single stream might even be
best overall, to reduce application complexity, and it seems to be what
most implementors are actually doing.

I know that leaves the DKG attack, but from a client and servers
perspective that attack is basically identical to a server timeout, and
it's something that systems likely have some fault tolerance around. It's
not /new/ broken-ness.

> these PRs and/or suggest other specific changes that we should make

Will do! Many thanks.

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 May 2017 20:21:33 -0700

> it's something that systems likely have some fault tolerance around. It's

Heh. Always happy to do less writing.

Thanks,
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 4 May 2017 12:34:30 +0300

> https://github.com/tlswg/tls13-spec/issues/1001

What I didn't see in the summary, but I think might be relevant in
relation to 0-RTT:

There is a thing called 0-RTT exporter, which are exporter values
available during 0-RTT transmission.

If the server uses 0-RTT exporter and doesn't enforce non-replay, the
value grossly fails to be "nonce", which means it is likely unsafe to
use for authentication.

Unfortunately, there are protocols that are already discussing the
use of TLS 1.3 0-RTT exporter, and switching to "full" exporter.
Unfortunately, the easiest way is not to switch, which means the
possibly weak 0-RTT exporter will be used for authenticating even
non-replayable data.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Thu, 4 May 2017 17:07:37 +0000

IMHO what we have is a facility in TLS 1.3 that:
1. Requires extraordinary effort on the server side to mitigate replay (for all but the smallest deployments);
2. Offers no way for the client to determine whether the server is mitigating replay (before replay becomes possible);
3. Is trivial to enable on the client and improves connection latency;
4. Eliminates a nonce that other protocols (used to) rely on.

While it is true that there are cases where this facility is beneficial, there is no doubt that it will be widely misused, in both applications and protocols.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Thursday, May 4, 2017 2:35 AM
To: Colm MacCárthaigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote:
> On Sunday at the TLS:DIV workshop I presented a summary of findings of 
> a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
> Thanks to feedback in the room I've now tightened up the findings from 
> the review and posted them as an issue on the draft GitHub repo:
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1001&data=02%7C01%7CAndrei.Popov
> %40microsoft.com%7C51d7739d6f4341108acb08d492d0cd8f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636294872882067868&sdata=HTQL9a3CxUEC0GkAQ%
> 2BviRMMO5ts2PnifQjOaZ%2BLZXR8%3D&reserved=0

What I didn't see in the summary, but I think might be relevant in relation to 0-RTT:

There is a thing called 0-RTT exporter, which are exporter values available during 0-RTT transmission.

If the server uses 0-RTT exporter and doesn't enforce non-replay, the value grossly fails to be "nonce", which means it is likely unsafe to use for authentication.

Unfortunately, there are protocols that are already discussing the use of TLS 1.3 0-RTT exporter, and switching to "full" exporter.
Unfortunately, the easiest way is not to switch, which means the possibly weak 0-RTT exporter will be used for authenticating even non-replayable data.

-Ilari

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C51d7739d6f4341108acb08d492d0cd8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636294872882067868&sdata=sgnwm3v7jfjLeWHZV77zwpchfzgy85ASKeKYYxEQxss%3D&reserved=0

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 11:03:12 -0700

On Thu, May 4, 2017 at 10:07 AM, Andrei Popov <[email-masked]>
wrote:

> 2. Offers no way for the client to determine whether the server is
> mitigating replay (before replay becomes possible);
>

I'm less worried about these problems. There's a nice property that the
operators of large deployments tend to also be technically sophisticated. I
don't think we'll have a problem implementing a single use cache, strike
register, we have similar systems for other services, at higher volumes.
It's a cost of being big, and that's ok.

It will be possible to tell whether a service permits replays; by trying
them. If the service permits them, that's a pretty clear CVE, and the usual
incentives work as well as they usually do.

> While it is true that there are cases where this facility is beneficial,
> there is no doubt that it will be widely misused, in both applications and
> protocols.
>

This doesn't need to be an anchor around the neck of the whole feature.
0-RTT is still an awesome speed benefit - if servers prevent replays, I
think we have a very good balance.

-- 
Colm

---

From: Andrei Popov <[email-masked]>
Date: Thu, 4 May 2017 18:22:42 +0000

*   I don't think we'll have a problem implementing a single use cache, strike register, we have similar systems for other services, at higher volumes.
… and these things work across geographically distributed datacenters, without negating the latency benefits of 0-RTT?

Cheers,

Andrei

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 11:26:27 -0700

On Thu, May 4, 2017 at 11:22 AM, Andrei Popov <[email-masked]>
wrote:

>
>    - I don't think we'll have a problem implementing a single use cache,
>    strike register, we have similar systems for other services, at higher
>    volumes.
>
> … and these things work across geographically distributed datacenters,
> without negating the latency benefits of 0-RTT?
>

They won't work across geographically distributed data centers, no, but I
don't think that's a significant problem. Providers already work hard to
maximize user affinity to a data center for other operational reasons;
re-routing is relatively rare and quickly repaired by issuing a new ticket.

-- 
Colm

---

From: Andrei Popov <[email-masked]>
Date: Thu, 4 May 2017 18:29:30 +0000

*   Providers already work hard to maximize user affinity to a data center for other operational reasons; re-routing is relatively rare and quickly repaired by issuing a new ticket.
Understood, but isn’t an attacker going to be able to re-route at will?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 11:32:48 -0700

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov <[email-masked]>
wrote:

>
>    - Providers already work hard to maximize user affinity to a data
>    center for other operational reasons; re-routing is relatively rare and
>    quickly repaired by issuing a new ticket.
>

Yes, but I don't see the significance.  If the attacker reroutes the user,
or replays a ticket, to a different data center - the ticket won't work,
it'll degrade gracefully to a regular connection.  Of course the attacker
succeeded in slowing the user down, but that's possible anyway.

Maybe you're thinking of a strike register that shares a global namespace?
That would be an implementation error; tickets should be scoped to the
location they are issued from, and checked against its strike register (or
not used at all).

-- 
Colm

---

From: Andrei Popov <[email-masked]>
Date: Thu, 4 May 2017 19:03:11 +0000

Indeed, as long as the scope of the ticket <= scope of the nonce database, it appears that rerouting wont’ help the attacker.
From: Colm MacCárthaigh [mailto:[email-masked]]
Sent: Thursday, May 4, 2017 11:33 AM
To: Andrei Popov <[email-masked]>
Cc: Ilari Liusvaara <[email-masked]>; [email-masked]
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Yes, but I don't see the significance.  If the attacker reroutes the user, or replays a ticket, to a different data center - the ticket won't work, it'll degrade gracefully to a regular connection.  Of course the attacker succeeded in slowing the user down, but that's possible anyway.

Maybe you're thinking of a strike register that shares a global namespace? That would be an implementation error; tickets should be scoped to the location they are issued from, and checked against its strike register (or not used at all).

--
Colm

---

From: Erik Nygren <[email-masked]>
Date: Thu, 4 May 2017 15:12:41 -0400

> both session-cache and strike register styles and the merits of each.

I don't believe this is technically viable for the large-scale server
operators most interested in 0-RTT.  Having session ticket reuse across
clusters is a requirement for performance, especially in cases such as
moving load between clusters.  In the cross-cluster case, neither session
caches nor strike registers are possible in the time-frames that are
interesting and relevant to 0-RTT (as strong consistency between clusters
has inherent latency that isn't possible in the 0-RTT time-frames).

I fear having a "SHOULD" requirement here is one that will be widely
ignored.

Anything stateful here defeats the purpose of session tickets and is also
far too vulnerable to DDoS attacks to be useful, especially when trying to
scale up
to large clusters.

Many of the discussions I've been in seem to have concluded that we should
always be assuming that 0-RTT data can and will be replayed, and
applications
and application protocols need to design and use it carefully, accordingly.

Some of these mechanisms (timestamps, strike registers, etc)
are useful for servers protecting themselves from DDoS attacks
but aren't useful against an adversary trying to actively exploit replays.

> Colm's original message).

I'm not entirely sure what back-ends are going to do here.  By the time
they gain visibility into this it is too late.

As some of us have been saying for awhile, we need to assume that 0-RTT
data is replayable and require application protocols and clients
implementing those protocols to define when and when it is not safe to
use.  For example, if exporters from 0RTT are not safe to use, we should
make that super-clear that this is not a safe use of 0RTT.

In the HTTP case, Patrick McManus has pointed out that many
application-layer clients will retry/replay non-idempotent POST operations
regardless even over 1RTT (and if the app doesn't, the user will just click
reload).  The best defense against these classes of issues is for
end-to-end application semantics rather than trying to provide properties
at the session  layer.

        Erik

>> and replay. On forward secrecy the main finding was that it's not necessary
>> to trade off Forward Secrecy and 0-RTT. A single-use session cache can
>> provide it, and with the modification that ekr has created in

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 14:39:54 -0500

> > both session-cache and strike register styles and the merits of each.

The SHOULD should say that the server-side needs to apply a replay cache
OR fallback onto a full exchange when the 0-rtt data payload involves a
non-idempotent operation.

> has inherent latency that isn't possible in the 0-RTT time-frames).

Making the SHOULD be about non-idempotent 0-rtt payloads is sufficient.

That is, if you're GETting something and the server correctly makes GET
idempotent, then you can accept 0-rtt without any replay cache checking.

A POST, on the other hand, should get the fallback-to-full-handshake
treatment.  (And, indeed, the application should not even bother with a
0-rtt POST.)

> I fear having a "SHOULD" requirement here is one that will be widely

It should not be ignored as to non-idempotent operations though!

> Anything stateful here defeats the purpose of session tickets [...]

Right.

> Many of the discussions I've been in seem to have concluded that we
> should always be assuming that 0-RTT data can and will be replayed,
> and applications and application protocols need to design and use it
> carefully, accordingly.

Correct.  See the above text about idempotency.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 4 May 2017 14:44:06 -0500

> non-idempotent operation.

You seem confused on this key point.  The server commits to accepting or
rejecting *all* early data, *before* it can look inside and see what it
is (in particular, whether or not it is idempotent).

> Correct.  See the above text about idempotency.

Which is why we (try to) make such a big deal about having an
application profile -- to write down what is actually idempotent.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 14:49:20 -0500

> is (in particular, whether or not it is idempotent).

Sure, that's fine.  You could run an HTTP server that only accepts
HEADs, GETs, maybe DELETEs, and accepts 0-rtt and have the client send
all POSTs and such to a different HTTP server.

> > [...]

It's one good reason, but we were doing that ages ago, before 0-rtt was
ever proposed.  (Well, Kerberos has a 0-rtt scheme, with very little
guidance on this point...)

Nico
--

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 4 May 2017 23:01:02 +0300

> and application protocols need to design and use it carefully, accordingly.

The problem is, the amount of replays is so great even non-idempotency
that is normally of no consequence becomes a major problem. It isn't one
or two or three replays, it could be _millions_ of replays.

Almost nothing is idempotent enough, unless extremely carefully designed,
and very few things are.

There are loads of GET endpoints there that don't have any wild non-
idempotent behaviour, but still aren't idempotent enough.

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 15:11:52 -0500

On Thu, May 04, 2017 at 11:01:02PM +0300, Ilari Liusvaara wrote:
> > applications and application protocols need to design and use it
> > carefully, accordingly.
> 

Adaptive fallback to full handshakes.

> Almost nothing is idempotent enough, unless extremely carefully designed,

GETs of static data are.

> idempotent behaviour, but still aren't idempotent enough.

Yes, this is true.  But the idea is that one should not enable 0-rtt for
servers that have such behavior.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 15:14:06 -0500

> all POSTs and such to a different HTTP server.

Also, a server could accept all sorts of 0-rtt data and at the
application-layer cause extra round-trips and force the client to
re-request.  Not all existing application protocols will support that,
naturally.  For HTTP... maybe a redirect?

Nico
--

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 13:21:43 -0700

> non-idempotent operation.

I don't mean to be dismissive with this but TLS stands for "Transport Layer
Security". The transport layer just isn't aware of what the operations are,
and whether then can be idempotent (99% of the time, the answer is "no").
Only the application can tell, but this violation of layers is what leads
to so many problems. I don't think it's workable.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 13:24:30 -0700

On Thu, May 4, 2017 at 12:12 PM, Erik Nygren <[email-masked]> wrote:

> operators most interested in 0-RTT.
>

I think it is (and work at one of the biggest) ... but if even it weren't,
that would just imply that we can't have 0-RTT at all, not that it's ok to
ship an insecure version.

-- 
Colm

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 15:26:52 -0500

> to so many problems. I don't think it's workable.

I don't mean to be dismissive, but it doesn't matter what "TLS" stands
for.  It does what we make it do via Standards Action at the IETF.  We
follow our rules for everything to do with development of Internet
Standards and publication of Experimental, Informational and BCP RFCs.

We have a process.  If you don't like what we're doing, you can voice
your opinion.  If you don't like the outcome of consensus calls and/or
IESG decisions, you can appeal those.

Thanks,

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 May 2017 14:13:19 -0700

As promised:
https://github.com/tlswg/tls13-spec/pull/1005

Note: I may have to do a little post-landing cleanup, but I wanted to get
people's senses of the text ASAP.

Comments welcome.
-Ekr

---

From: Kyle Nekritz <[email-masked]>
Date: Thu, 4 May 2017 21:27:40 +0000

> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both session-cache and strike register styles and the merits of each.

First, a point of clarification, I think two issues have been conflated in this long thread:
1) Servers rejecting replayed 0-RTT data (using a single use session cache/strike register/replay cache/some other method)

There are definitely cases (i.e. application profiles) where this should be done. I think a general case HTTPS server is one. But I don’t think this is strictly necessary across the board (for every application using 0-RTT at all). DNS was brought up earlier in this thread as an example of a protocol that is likely quite workable without extra measures to prevent replay.

We already state “Protocols MUST NOT use 0-RTT data without a profile that defines its use.”. We could also describe methods that may be used to provide further replay protection. But I don’t think it’s appropriate to make a blanket requirement that *all* application protocols should require it.

I also consider it quite misleading to say TLS 1.3 is insecure without such a recommendation. Uses of TLS can be insecure, that does not mean the protocol itself is. It’s insecure to use TLS without properly authenticating the server. Some users of TLS do not do this correctly. I’d actually argue that it is easier to mess this up than it is to mess up a 0-RTT deployment (and it can result in worse consequences). That doesn’t mean we should require a particular method of authentication, for all uses of TLS.

2) Preventing clients from sending 0-RTT data multiple times (on separate connections) using the same PSK (for forward secrecy reasons)

I think this should be allowed. Otherwise, clients will not be able to retry 0-RTT requests that fail due to an unknown network error prior to receiving a NST (if they are out of cached PSKs). I’d expect the need for these retries to be larger with 0-RTT data, particularly when 0-RTT data is sent without even a transport roundtrip (in the case of TFO or QUIC). Servers are definitely not required to accept multiple 0-RTT connections using the same PSK, but I don’t think clients should be banned from attempting.

> 2. Document 0-RTT greasing in draft-ietf-tls-grease

I’m not convinced this is actually a productive thing to do in the same manner as grease, particularly if servers are taking anti-replay measures (in which case I see this being useful in a TLS testing tool like ssllabs, but not in actual deployments). I think we can leave this discussion for later though.

> 3. Adopt PR#448 (or some variant) so that session-id style implementations provide PFS.

Sounds good to me.

> 4. I would add to this that we recommend that proxy/CDN implementations signal which data is 0-RTT and which is 1-RTT to the back-end (this was in Colm's original message).

I’m not sure that the TLS 1.3 spec is the right place to make recommendations for this. I can see several reasonable approaches here, for example:
- Adding some kind of application level annotation (for example an HTTP header)
- Robustly preventing replay on the 0-RTT hop
- Sending proxied early data with a different TLS ContentType, etc.
I don’t see a need to specifically endorse any particular method here.

There was also a point brought up about the use of ticket_age without 0-RTT. I’m not aware of any use for ticket_age other than 0-RTT replay protection. I believe that ticket_age is sent with all PSKs mostly out of convenience/consistency. I don’t really have an objection to the current method, but I also wouldn’t be opposed to moving the ticket age to the early data extension, so that it is only sent along with 0-RTT data.
It also seems a little under-specified what implementations unable to compute a reasonable ticket age should send (for example in the case of a device without a real time clock, or with an external PSK).

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, May 3, 2017 11:13 PM
To: Colm MacCárthaigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

Hi folks,

I made some proposals yesterday
(https://www.ietf.org/mail-archive/web/tls/current/msg23088.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23088.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=XgHbUwT6upAsOin4T6P8ePs8i0ZFsnD-_BNvueeq83E&e=>).

Specifically:

Thanks,
-Ekr

On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh <[email-masked]<mailto:[email-masked]>> wrote:
On Sunday at the TLS:DIV workshop I presented a summary of findings of a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. Thanks to feedback in the room I've now tightened up the findings from the review and posted them as an issue on the draft GitHub repo:

On replay, the main finding is that what's in the draft is not workably secure, and the review includes 5 different attacks against 0-RTT data to illustrate that. Attacks 1 and 2 show that the kind of replay permitted by the draft is very different from the kind of replay permitted by dkg's existing downgrade-and-retry attack. I also go over why it very very difficult to many applications to achieve that idempotency, and why one idempotency pattern actually relies on non-replayable messages.

Attack 3 shows that idempotency is not sufficient, applications must also be free of measurable side-effects, which is not practical.  Attack 4 shows that 0-RTT breaks a common security mechanism: spoofing-resistant throttles. Attack 5 shows that 0-RTT replay-ability enables an additional form of traffic analysis.

The recommendation in the review is that implementations "MUST" prevent replays of 0-RTT section, with some additional discussion about why the existing advice is unlikely to be followed, and why consistent interoperability matters here.

Unfortunately, I wasn't aware until Friday that this review would be coming so late in the TLD1.3 draft process, and my apologies for that. I am now planning to attend the future WG in-person meetings and look forward to seeing many of you there.

--
Colm

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=6GIocGzW6wPK4EAlqDLIirNvsuQj7gWhYG_OzROR2qY&e=>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 May 2017 14:37:20 -0700

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <[email-masked]> wrote:

> 1) Servers rejecting replayed 0-RTT data (using a single use session
> cache/strike register/replay cache/some other method)
>
>
>
> There are definitely cases (i.e. application profiles) where this should
> be done. I think a general case HTTPS server is one. But I don’t think this
> is strictly necessary across the board (for every application using 0-RTT
> at all). DNS was brought up earlier in this thread as an example of a
> protocol that is likely quite workable without extra measures to prevent
> replay.
>
>
>
> We already state “Protocols MUST NOT use 0-RTT data without a profile that
> defines its use.”. We could also describe methods that may be used to
> provide further replay protection. But I don’t think it’s appropriate to
> make a blanket requirement that *all* application protocols should require
> it.
>
>
>
> I also consider it quite misleading to say TLS 1.3 is insecure without
> such a recommendation. Uses of TLS can be insecure, that does not mean the
> protocol itself is. It’s insecure to use TLS without properly
> authenticating the server. Some users of TLS do not do this correctly. I’d
> actually argue that it is easier to mess this up than it is to mess up a
> 0-RTT deployment (and it can result in worse consequences). That doesn’t
> mean we should require a particular method of authentication, for all uses
> of TLS.
>

I think this is basically right. In the PR I just posted, I spent most of
my time describing the
mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
I think there's a bunch of room to wordsmith the requirement. Perhaps we
say:

- You can't do 0-RTT without an application profile
- Absent the application profile saying otherwise you SHOULD/MUST do one of
these mitigations?

2) Preventing clients from sending 0-RTT data multiple times (on separate
> connections) using the same PSK (for forward secrecy reasons)
>
>
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior to
> receiving a NST (if they are out of cached PSKs). I’d expect the need for
> these retries to be larger with 0-RTT data, particularly when 0-RTT data is
> sent without even a transport roundtrip (in the case of TFO or QUIC).
> Servers are definitely not required to accept multiple 0-RTT connections
> using the same PSK, but I don’t think clients should be banned from
> attempting.
>

I agree, and the PR I provided doesn't attempt to do so.

> I’m not sure that the TLS 1.3 spec is the right place to make
> recommendations for this. I can see several reasonable approaches here, for
> example:
>

I think Colm has also agreed we shouldn't do this and it's not in my PR.

>
>
>
> There was also a point brought up about the use of ticket_age without
> 0-RTT. I’m not aware of any use for ticket_age other than 0-RTT replay
> protection. I believe that ticket_age is sent with all PSKs mostly out of
> convenience/consistency. I don’t really have an objection to the current
> method, but I also wouldn’t be opposed to moving the ticket age to the
> early data extension, so that it is only sent along with 0-RTT data.
>

I would be OK with this as well. It does seem slightly more elegant.

> It also seems a little under-specified what implementations unable to
> compute a reasonable ticket age should send (for example in the case of a
> device without a real time clock,
>

Right. I have been basically assuming that you can't really do TLS without
a real-time clock, but maybe that's wrong?

> or with an external PSK).
>

This actually is well-specified (though maybe wrong)
"For identities established externally an obfuscated_ticket_age of 0 SHOULD
be used, and servers MUST ignore the value."
https://tlswg.github.io/tls13-spec/#pre-shared-key-extension

-Ekr

> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Wednesday, May 3, 2017 11:13 PM
> *To:* Colm MacCárthaigh <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Security review of TLS1.3 0-RTT
>
>
>
> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23088.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=XgHbUwT6upAsOin4T6P8ePs8i0ZFsnD-_BNvueeq83E&e=>
> ).
>
>
>
> Specifically:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=6GIocGzW6wPK4EAlqDLIirNvsuQj7gWhYG_OzROR2qY&e=>
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 May 2017 16:58:19 -0500

> - Absent the application profile saying otherwise you SHOULD/MUST do one of

There's a number of ways to handle this.

One is to say that 0-rtt cannot be enabled by default, and that enabling
it requires an API call or application profile that puts the onus of
understanding the ramifications on the application developer.

The thing to keep in mind is that this RFC can give guidance to TLS
implementors, and to authors of Internet protocols using TLS.  It can't
really give guidance to authors of non-Internet protocols using TLS:
they might never look at the RFC.  So the guidance here has to be for
the available audience.  For TLS implementors the guidance should be to
make the 0-rtt footgun clear to consuming applications.

Nico
--

---

From: Erik Nygren <[email-masked]>
Date: Thu, 4 May 2017 18:00:13 -0400

On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla <[email-masked]> wrote:

>> We already state “Protocols MUST NOT use 0-RTT data without a profile
>> that defines its use.”. We could also describe methods that may be used to
> - Absent the application profile saying otherwise you SHOULD/MUST do one
> of these mitigations?
>

I generally agree with Kyle here (and also added a few minor comments to
the PR).
I think we should be clear where the responsibilities generally lie as
well, for example:

"The onus is on clients not to send messages in 0-RTT data which are not
safe to have replayed and which they would not be willing to retry across
multiple 1-RTT connections. The onus is on servers to protect themselves
against attacks employing 0-RTT data replication."

The server responsibility is a general property TLS can maintain while the
client responsibility requires an application profile to define.

        Erik

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 May 2017 15:03:19 -0700

On Thu, May 4, 2017 at 3:00 PM, Erik Nygren <[email-masked]> wrote:

>>> > 1. A SHOULD-level requirement for server-side 0-RTT defense,
>>> explaining both session-cache and strike register styles and the merits of
>>> each.
>>>
>>>
>>>

These seem like good changes. I will work to incorporate them.

-Ekr

---

From: Kyle Nekritz <[email-masked]>
Date: Thu, 4 May 2017 22:04:05 +0000

Yep, I think your PR is in the right direction.

> I have been basically assuming that you can't really do TLS without a real-time clock, but maybe that's wrong?

Well, it’s possible, although I do not know if anyone actually does (and of course certificate validation would be a little challenging). Maybe someone from the embedded crowd can enlighten us.

> "For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value."

Ah, I had missed that. I think the MUST might be a little strong there, even without direct involvement of the server in issuing the external PSK the ticket age can still be useful, for example using a similar method we use with Zero Protocol (Time-bound 0-RTT data section of https://code.facebook.com/posts/608854979307125/building-zero-protocol-for-fast-secure-mobile-connections/ ).

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, May 4, 2017 5:37 PM
To: Kyle Nekritz <[email-masked]>
Cc: Colm MacCárthaigh <[email-masked]>; [email-masked]
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

I think this is basically right. In the PR I just posted, I spent most of my time describing the
mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
I think there's a bunch of room to wordsmith the requirement. Perhaps we say:

- You can't do 0-RTT without an application profile
- Absent the application profile saying otherwise you SHOULD/MUST do one of these mitigations?

It also seems a little under-specified what implementations unable to compute a reasonable ticket age should send (for example in the case of a device without a real time clock,

Right. I have been basically assuming that you can't really do TLS without a real-time clock, but maybe that's wrong?

This actually is well-specified (though maybe wrong)
"For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value."
https://tlswg.github.io/tls13-spec/#pre-shared-key-extension<https://urldefense.proofpoint.com/v2/url?u=https-3A__tlswg.github.io_tls13-2Dspec_-23pre-2Dshared-2Dkey-2Dextension&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=00D34eqyobqYsnH-0x2sQdC8Xn1GCqHQBFPqPeXE0gg&s=pachGLJQErJG8nAK5OKJ4L3Da70bIO1BQlytdiuuaNs&e=>

-Ekr

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Wednesday, May 3, 2017 11:13 PM
To: Colm MacCárthaigh <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

Hi folks,

Specifically:

Thanks,
-Ekr

--
Colm

---

From: Derrell Piper <[email-masked]>
Date: Thu, 4 May 2017 16:04:26 -0600

Sure, those are fine weasel words.  But do we really want to allow into this protocol something that can be misused with security implications in a protocol that’s attempting to solve a security problem?  I really don’t know.  I’m inclined to say, ‘no’ though.  For all those same reasons that IPsec provides replay detection, I think TLS should too.

Derrell

> On May 4, 2017, at 4:00 PM, Erik Nygren <[email-masked]> wrote:
> 
> "The onus is on clients not to send messages in 0-RTT data which are not safe to have replayed and which they would not be willing to retry across multiple 1-RTT connections. The onus is on servers to protect themselves against attacks employing 0-RTT data replication."
> 
> The server responsibility is a general property TLS can maintain while the client responsibility requires an application profile to define.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 4 May 2017 16:26:48 -0700

> protocol that is likely quite workable without extra measures to prevent

I thought some more about DNS since yesterday and I'm not sure it is
workable. How would we protect DNS against attack 4 (cache replay) -
couldn't it lead to disclosure of what the request was for? When used
against caches I mean, which is common, and DNS-over-TLS is designed mainly
for privacy, so that actually seems like a show-stopper.

> mean we should require a particular method of authentication, for all uses

Here's how I think about it. Each of the attacks in the review is more
practical than Lucky13. More practical in the sense that I could do them in
a real-world setting. In my view at least.

Lucky13 was serious enough to prompt us all to accelerate turning of the
MtE cipher suites. Even though this actually made traffic analysis attacks
easier. Collectively we took a look at it and decided it was on too shaky
ground and we considered it insecure. And so the MtE suites went away.

I can't find a way then, in that context, to see replay as anything other
than a straightforward security issue. Replay is bad, it breaks things,
that's why we go to lengths to prevent it, it's not ok to just for get
about that. If TLS allows replay, TLS is insecure. Remembering that TLS is
a transport layer protocol, not an application layer one.

An application can use RC4 at the TLS layer if it provides its own
application-layer encryption, but we don't consider that secure. We don't
look for cases where applications can make special exceptions; because
that's fraught with sharp edges. We make the default secure.

-- 
Colm

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 May 2017 00:07:09 -0500

Trying to consolidate various things into a single mail...

On 05/04/2017 04:37 PM, Eric Rescorla wrote:
> In the PR I just posted, I spent most of my time describing the

That seems like an inconsistent position to take (don't do this, but if
you ignore me, do this in this fashion).  Advising application profiles
to consider one of those things might be better.

On 05/04/2017 04:27 PM, Kyle Nekritz wrote:
>
> 2) Preventing clients from sending 0-RTT data multiple times (on
> separate connections) using the same PSK (for forward secrecy reasons)
>
>  
>
> retry 0-RTT requests that fail due to an unknown network error prior
> to receiving a NST (if they are out of cached PSKs). I’d expect the
> need for these retries to be larger with 0-RTT data, particularly when
> 0-RTT data is sent without even a transport roundtrip (in the case of
> TFO or QUIC). Servers are definitely not required to accept multiple
> 0-RTT connections using the same PSK, but I don’t think clients should
> be banned from attempting.
>

Obligatory note that if clients are forbidden from reusing a single PSK
for multiple 0-RTT, they can still use it for 1-RTT.

On 05/04/2017 03:24 PM, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:12 PM, Erik Nygren <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         explaining
>     I don't believe this is technically viable for the large-scale
>     server operators most interested in 0-RTT.
>
>
> I think it is (and work at one of the biggest) ... but if even it
> weren't, that would just imply that we can't have 0-RTT at all, not
> that it's ok to ship an insecure version.

I would be okay with that being the case ... but I don't think that's
actually the case.  Some people are going to do 0-RTT in one form or
another, whether or not we specify it here.  I'd rather have something
well-specified that can be used correctly in some cases and is
unfortunately used in more cases than that, then a
less-well-documented-and-analyzed thing used in those same questionable
cases.

> doesn't provide replay protection?

Some of the earlier uses of Kerberos are subject to replay (hence
kerberos implementations can end up providing replay caches to try and
help, which are not perfect and slow to boot).  More modern exchanges
that use GSS acceptor subkeys are not subject to replay, though.

On 05/03/2017 09:31 PM, Martin Thomson wrote:
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear.  Otherwise, beware.  The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactively blessed.

You can still be in trouble if you used the early exporter, e.g., for
token binding.  We had some discussions in the tokbind session in
Chicago that clarified that handshake completion does not retroactively
bless the properties you want from 0-RTT token binding.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 May 2017 22:12:34 -0700

On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk <[email-masked]> wrote:

> you ignore me, do this in this fashion).  Advising application profiles to
> consider one of those things might be better.
>

That's just incompetent writing by me, I guess.

For 2, I meant "If there is an application profile allowing 0-RTT, but it
doesn't say you don't
need mitigations, then you MUST..."

-Ekr

> unfortunately used in more cases than that, then a less-well-documented-and-analyzed
> thing used in those same questionable cases.
>
>
> Some of the earlier uses of Kerberos are subject to replay (hence kerberos
> implementations can end up providing replay caches to try and help, which
> are not perfect and slow to boot).  More modern exchanges that use GSS
> acceptor subkeys are not subject to replay, though.
>
>
> token binding.  We had some discussions in the tokbind session in Chicago
> that clarified that handshake completion does not retroactively bless the
> properties you want from 0-RTT token binding.
>
>
> -Ben
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 5 May 2017 13:22:28 +0300

> need mitigations, then you MUST..."

I think the two methods (use-once session database and strike register)
should additionally be formulated so that those have sufficient
atomicity to eliminate 0-RTT replay.

This of course impiles that the scope of 0-RTT is sufficiently small
for synchronization to propagate quickly enough (this probably limits
the scope to a datacenter, but this should not be a problem in
practice).

Then clients should also be restricted to using the same ticket just
once for 0-RTT (absent a application profile), with due atomicity.

Also, I think use of 0-RTT exporters should require atomic session
database or strike register, no matter what application profile says,
as otherwise 0-RTT exporters become insecure.

Obviously, these 0-RTT safeguards don't need to apply to 1-RTT using a
dynamic PSK. That can be reused (obiviously at cost of linkability).

Also, a trick: The first binder makes a good identifier for the
ClientHello for purposes of 0-RTT replay detection.

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Fri, 5 May 2017 11:45:47 -0500

> that use GSS acceptor subkeys are not subject to replay, though.

We might be getting far afield now, but if you're not using "mutual
auth" then GSS/Kerberos will look a lot like TLS 1.3 0-rtt.  GSS apps
that want that need to be careful, just as TLS 1.3 0-rtt apps.

Also, even for the 1-rtt case, GSS/Kerberos supports early (0-rtt) data.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Sat, 6 May 2017 17:35:36 -0700

On 5/4/2017 10:12 PM, Eric Rescorla wrote:
>
> Obligatory note that if clients are forbidden from reusing a single
> PSK for multiple 0-RTT, they can still use it for 1-RTT.

Yes, they can. But doing so leaks a unique identifier, which can be used
to link sessions. When I look at the privacy implications as well as the
replay attacks, there is real value in using a resume ticket only once.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 6 May 2017 17:51:24 -0700

> replay attacks, there is real value in using a resume ticket only once.

Agreed.  Also, I think that's Ben Kaduk you're quoting :)

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 7 May 2017 05:27:17 -0400

> On May 6, 2017, at 8:51 PM, Eric Rescorla <[email-masked]> wrote:
> 

Agreed, on the general case, but a reminder that not all applications
benefit from such "privacy".  A sending SMTP MTA has a fixed public
IP address, and even sends a fixed fixed SMTP "HELO" name in the clear
before STARTTLS.  It might of course also send SNI in the clear, ...
and will typically perform cleartext DNS queries that identify the
peer.  There is exceedingly little opportunity or desire to hide client
and server host names.  So some applications will reuse session tickets
(while avoiding 0-RTT).

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 17:39:55 -0700

> people's senses of the text ASAP.

Thanks for everyone's comments. I've updated the text to address many of
them and
made comments in Github where I decided not to do so. Can those who have
read
the previous version please take a look?

I'd also like to merge PR#998. I haven't heard any real complaints about it
and it's
an improvement in any case. I'll await the chairs on that, though.

-Ekr

Comments welcome.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 May 2017 12:53:17 +0300

> the previous version please take a look?

To me, that reads as gross understatement about the dangers involved in
0-RTT:

- The side channel attacks with millions or billions of replays are hard
  to protect against. This is if the side channels are in TLS library.
  If not, protecting against that sort of side channels becomes
  virtually impossible.
- Furthermore, with that kind of replay volume, protecting against DoS
  attacks is virtually impossible.
- Even if once-per-server or once-per-cluster replay detection limits
  the number of replays to few hundred to few thoursand at maximum,
  where the low-level crypto side channels are much less of a threat,
  cache attacks can be used to break security (in fact, not sending a
  mad burst of data to any one server is useful for carrying out these).
- 0-RTT Exporters are severly broken unless servers do strict anti-
  replay.

(I left unordered replay out, because I don't see how that is
actually created by 0-RTT, as opposed to just being made easier).

There are no inherent problems in 0-RTT that I know of that would
prevent sending even non-idempotent things like HTTP POSTs over it
(however, failure rates are increased if you do). However, as
currently described, I would not think 0-RTT is safe for anything
except very boring things like protocol banners. I also do not
consider it safe enough to implement in anything that actually
considers security.

Also, on 0-RTT enable/disable: I would imagine that some browsers at
first might have an option to disable 0-RTT. However, I expect that
over time it will get removed (like what happened with the session
ticket support in Firefox), so when serious problem is discovered, there
is no option to disable the vulernable feature at all (like happened
with tickets in TLS 1.0-1.2) or the disable is far too wide (e.g.
disabling whole TLS 1.3 in order to disable 0-RTT).

Also, the kind of thing going on here seems exactly how I would imagine
the past very bad decisions from TLS WG, that were known to be insecure
at the time of specification and where then successfully attacked later,
played out. However, I have not read those discussions from the ML
archives.

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 19 May 2017 09:59:57 -0700

>   mad burst of data to any one server is useful for carrying out these).

I wouldn't be too fatalistic about it. The speed of light is too slow for
human interaction, and 0-RTT is an important and awesome feature that we
should make safe and near universal.

Some protection is necessary; but it isn't too hard - a single-use session
cache, or a strike register, do protect against the side-channel and DOS
problems. Combined with a "fail closed" strategy and tickets that are
scoped to clusters or servers, these techniques do hard-stop the literal
0-RTT replays, and they are practical. Many of us run systems like that
already.

> played out. However, I have not read those discussions from the ML

In this case, I think people see the trade-offs differently and that's ok.
There's a sense that the risks or cost are worth it. After all, you can
mitigate a lot of the risk if you have a team of experts on standby who
manually mitigate these kinds of attacks, or more advanced automated
response systems. And many big providers do have both of these.

What concerns me most is that the 0-RTT interactions here are formalizable
and that the messaging interactions can be modeled in TLA+, F*, etc ... but
that hasn't been done as it has with the rest of the TLS1.3 state machine.

My TLA+ simple model convinced me that what's in the draft doesn't actually
work; there's nothing in the messages that allows a server to de-dupe, I
wrote up a simple 3-message example of this earlier in the thread, and it
seems to hold to the breaking the "X-" header trick that one provider came
up with.  That already in this draft deployment phase, that can advanced,
knowledgable, provider's attempt at a mitigation can be shown to be broken
should be cause for alarm. It's not a safe set-up.

Here's all I think we need to fix all of this though, in order of priority:

For relatively "Normal" clients (e.g. Browsers):

* Servers supporting 0-RTT need to robustly prevent replay of literal 0-RTT
sections. No time-based mitigation, which simply doesn't work. This is the
"cost" of doing 0-RTT.
* Clients should be the real arbiter of what to use 0-RTT; e.g. never use
for POST, etc. This could bear some emphasis. It's important because
middle-boxes exist.

For careful clients, think about something implementing a transaction over
TLS:

* If a 0-RTT section is sent but does not result in a successful receipt,
that failure needs to be signaled to the client.
* In order to fully reason about when that message may later get received,
there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all
potential middle-boxes in the pipe that may be using 0-RTT.

And then separate to all of the above, and lower priority:

* There's a contradiction between the obfuscated ticket age add parameter
and the desire to use tickets multiple times in other (non-0RTT) cases. We
can't do one without defeating the point of the other. Either remove the
obfuscation because it is misleading, or move it into an encrypted message
so that it is robust.

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 May 2017 21:40:51 +0300

> 0-RTT replays, and they are practical. Many of us run systems like that

Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
even with distributed servers for the origin.

Of course, this impiles that there is some small-enough spatial scope
for 0-RTT, so servers in scope can reach global consistency in acceptable
time (which also sets the server timeout!)

Latencies within a single datacenter should be pretty low, and routing
should be pretty sticky between datacenters.

> for POST, etc. This could bear some emphasis. It's important because

Yeah, for clients that are as careless with HTTP as browsers, sending
POSTs in 0-RTT data is very bad idea.
 
> that failure needs to be signaled to the client.

This is already required in order to implement HTTP semantics. E.g. so
that if 0-RTT section contains POST request, the HTTP library can signal
its client "failed: connection to server lost before reply was
received" (and retry GETs, PUTs and DEETEs).

> potential middle-boxes in the pipe that may be using 0-RTT.

Isn't that potentially multi-party problem if middleboxes are involved?

> obfuscation because it is misleading, or move it into an encrypted message

The purpose of obfustication is not to hide sibling sessions. The
client already blows its cover by using the same session ID twice. The
purpose of obfustication is to hide the parent session.

Are you talking about attackers being able to determine the rate of
client clock?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 May 2017 14:44:32 -0400

> even with distributed servers for the origin.

I don't disagree with that necessarily, but if the client responds by
retransmitting
in 1-RTT, then you don't have overall at-most-once.

-Ekr

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 19 May 2017 13:10:29 -0700

> Isn't that potentially multi-party problem if middleboxes are involved?

Yes; but if we can agree on a hard maximum time-window for the 0RTT
section, and all of the parties agree, it's possible for a careful client
to negotiate its way around it. Even if it's 10 seconds, this still has
some value I think.

> Are you talking about attackers being able to determine the rate of

Right now if a ticket is used multiple times, then the ticket age can be
derived (trivial cryptanalysis due to re-using the same obfuscated offset,
and because the progression of time between the ticket uses is public);
that means the parent session can be identified. So the point is defeated.

Either the one-time-pad can be used just one time (which means the ticket
can be used just once) or we should move it to an encrypted message. Or
just get rid of it and not be so misleading. But the current state is
weird, to say the least.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 19 May 2017 13:18:29 -0700

> in 1-RTT, then you don't have overall at-most-once.

Obviously this is fine for browsers; retry's make sense there anyway, and
so if we prevent mass-replay then there are no new attacks like the
side-channels and DOSes.

If a client needs to be more careful; with a hard-time limit on ticket use,
it can actually reason its way to at-most-once. It needs to wait out the
time limit, then do a read; to see if the original attempt succeeded or
not, and only then retry. That's a fairly common mode in eventually
consistent systems, loss-tolerant protocols and distributed consensus
protocols. For example some S3 clients and PAXOS systems work like this.

Of course it's very inconvenient to have to sometimes block for 10 seconds
(or whatever we pick), in return for a speed up of maybe as much as ~200ms
in the "ordinary" case; but it's the kind of trade-off that an
instrumentation system might make; like an industrial controller - where
day-to-day system liveness is a massive optimization benefit and the
occasional interruption is no big deal.

Super esoteric, and maybe we shouldn't even think too much about it, but I
bring it out because that construction is the only one I've found that gets
to at-most-once delivery; and it highlights that the existing system
explicitly doesn't and might just be needless complexity (the multiple
streams signaling).

-
Colm

---

From: David Benjamin <[email-masked]>
Date: Fri, 19 May 2017 20:49:42 +0000

Seeing as this utterly ridiculous ticket_age_add thing is partially my
fault, I suppose I should respond:

> that means the parent session can be identified. So the point is defeated.

Could you expand on your cryptanalysis? I don't believe this is actually
leaked. It's addition mod 2^32, not XOR, which means you effectively
randomize the parent starting time. (It was initially XOR, and then
shortly changed
to addition
<https://www.ietf.org/mail-archive/web/tls/current/msg20376.html>.)
Consider:

initial connection at time t1, issues a ticket with ticket_age_add = x. Let
t1' = t1 - x.
Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 +
x = t2 - t1'.
Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The
attacker learns t3 - t1 + x = t3 - t1'.

x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well. This
is a one-time pad on t1, correctly used only once. x is only ever used to
encrypt one timestamp, t1.

Of course, the attacker can correlate t2 and t3 by subtracting the two
public values and checking against the public difference between
connections they observe. But the ticket's already leaked anyway.

> just get rid of it and not be so misleading. But the current state is

I believe stuffing something into an AEAD was proposed and then rejected by
the cryptographers for some reason? You'd have to ask other folks for
details. I just recall being told that was a previous rejected proposal.
Accordingly, I suggested the dumbest thing that could possibly work,
intending it be so dumb that it could not possibly have consequences beyond
patching that correlation hole. :-)

David

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 19 May 2017 16:58:32 -0400

> On May 19, 2017, at 4:49 PM, David Benjamin <[email-masked]> wrote:
> 
> Could you expand on your cryptanalysis? I don't believe this is actually leaked. It's addition mod 2^32, not XOR, which means you effectively randomize the parent starting time. (It was initially XOR, and then shortly changed to addition.) Consider:
> 
> initial connection at time t1, issues a ticket with ticket_age_add = x. Let t1' = t1 - x.
> Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 + x = t2 - t1'.
> Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The attacker learns t3 - t1 + x = t3 - t1'.
> 
> x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well. This is a one-time pad on t1, correctly used only once. x is only ever used to encrypt one timestamp, t1.
> 
> Of course, the attacker can correlate t2 and t3 by subtracting the two public values and checking against the public difference between connections they observe. But the ticket's already leaked anyway.

+1.  The additive obfuscation leaks nothing that is not already leaked just by sending the tickets.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 19 May 2017 15:06:45 -0700

> just by sending the tickets.

You're both right, that does work out. I was thinking my balanced equations
stupidly and solving for x while forgetting that t1' is secret.

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 May 2017 18:46:32 -0400

On Fri, May 19, 2017 at 4:49 PM, David Benjamin <[email-masked]>
wrote:

> randomize the parent starting time. (It was initially XOR, and then shortly changed
> to addition
> x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well.
> This is a one-time pad on t1, correctly used only once. x is only ever used
> to encrypt one timestamp, t1.
>
> I believe stuffing something into an AEAD was proposed and then rejected
> by the cryptographers for some reason? You'd have to ask other folks for

What was rejected was actually having the stuffed Finished be an
AEAD-encrypted block
containing stuff like the ticket_age. We could certainly derive a new key
and AEAD it if
we wanted to, that just seemed like a lot more work than I think people
wanted to do.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 May 2017 12:33:47 +0300

> to negotiate its way around it. Even if it's 10 seconds, this still has

I meant what prevents the (say 10 second) windows from stacking up into
(say 20 second windows) if 0-RTT is used on multiple hops (client-
middlebox and middlebox-server)?

One can not assume that the client has knowledge of any middlebox on
the path (e.g. CDNs in HTTP are in general invisible to the client).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 May 2017 13:16:16 +0300

> 0-RTT replays, and they are practical. Many of us run systems like that

As requirements:

- Clients SHOULD NOT use the same ticket multiple times.
- Clients MUST NOT use the same ticket multiple times for 0-RTT.
- Servers MAY accept the same ticket multiple times.
- Servers MUST NOT accept the same ticket with the same binder multiple
  times for 0-RTT (if any part of ClientHello covered by binder is
  different, one can assume binders are different). This holds even
  across servers (i.e., if server1 accepts 0-RTT with ticket X and
  binder Y, then server2 can not accept 0-RTT with ticket X and binder
  Y).

The "with the same binder" requirement is to deal with the following:

1) Bad client sends 0-RTT with ticket X and in-window age age1.
2) Some days pass...
3) Bad client sends 0-RTT with ticket X and in-window age age2.

Without the "with the same binder", that would mean the server MUST
reject the 0-RTT for 3), which would mean keeping state for days,
which leads to excessive resource usage.

With the "with same binder", the server can time out the state for
1) as soon as the age1 is out-of-window. And then it MAY accept
0-RTT for 3). This will not lead into mass replay possibility for
either 1) nor 3).

The part of assuming binders different if any part covered is
different comes from strong hash requirement TLS 1.3 has.

?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 May 2017 18:47:22 -0400

> - Clients SHOULD NOT use the same ticket multiple times.

This is already in the document.

> - Clients MUST NOT use the same ticket multiple times for 0-RTT.

I don't understand the purpose of this requirement. As you note below,
servers are ultimately responsible for enforcing it, and it's not clear to
me why clients obeying it makes life easier for the server.

> - Servers MAY accept the same ticket multiple times.

This seems implicit.

>   binder Y, then server2 can not accept 0-RTT with ticket X and binder

I assume that what you have in mind here is that the server would know
which tickets it was authoritative for anti-replay and would simply reject
0-RTT if it wasn't authoritative? This seems like it would significantly cut
down on mass replays, though it would of course still make application-level
replay a problem.

I'm happy to write this up as part of the first two techniques. I'd be
interested in hearing from others in the WG what they think about:

1. Requiring it.
2. Whether they still want to retain the stateless technique.

-Ekr

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 21 May 2017 19:28:45 -0700

> me why clients obeying it makes life easier for the server.

I think clients should duplicate them sometimes, just to keep servers on
their toes ;-) this is what we talked about maybe being a grease thing ..
if at all.

> 2. Whether they still want to retain the stateless technique.

I'm for requiring it, and for removing the stateless technique ... because
it prevents the side-channel and DOS attacks and those seem like the most
serious ones (and also, the new ones).

So far each case where we've thought "Actually stateless might be ok in
this case" ... like the example of DNS ... turns out not to be safe when
examined more closely (in DNSes case it would compromise privacy because
caches could be probed).

-- 
Colm

---

From: Christian Huitema <[email-masked]>
Date: Sun, 21 May 2017 22:26:04 -0700

On 5/21/2017 7:28 PM, Colm MacCárthaigh wrote:
>
>
> On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <[email-masked]
>     ...
> I'm for requiring it, and for removing the stateless technique ...
> because it prevents the side-channel and DOS attacks and those seem
> like the most serious ones (and also, the new ones). 
>
> So far each case where we've thought "Actually stateless might be ok
> in this case" ... like the example of DNS ... turns out not to be safe
> when examined more closely (in DNSes case it would compromise privacy
> because caches could be probed). 

I would much rather see this specified within TLS than within the
application. Specifically, I would not like to see application making
statements that they can only use 0-RTT if the TLS software that they
use does implement "at most once" limitations on 0-RTT tickets. You
know, pretty much like those security sections that explain than a
careless application will be safe if it runs over IPSEC. Maybe with some
RFC 6919 language.

-- Christian Huitema

---

From: Kyle Nekritz <[email-masked]>
Date: Mon, 22 May 2017 17:12:19 +0000

The stateless technique certainly doesn’t solve all issues with replay. Neither do the other techniques, unless a fairly unrealistic (imo, in most use cases) retry strategy is used. But the stateless technique is definitely an improvement over no anti-replay mechanism at all (for instance it reduces the possible number of rounds of a cache probing attack, assuming the cache TTL > replay window). Which mechanisms to use, and whether to enable 0-RTT in the first place (or PSK mode at all), should be decided considering the tradeoff between security/performance/implementation constraints, etc. In the case of DNS, most DNS security protocols (dnssec, etc.) do allow this kind of replay so I think it is a pretty reasonable tradeoff to consider.

Additionally, I think the stateless technique is quite useful as a defense-in-depth mechanism. I highly doubt all deployments will end up correctly implementing a thorough anti-replay mechanism (whether accidentally or willfully). The stateless method is very cheap, and can be implemented entirely within a TLS library even in a distributed setup, only requiring access to an accurate clock. I’d much rather deployments without a robust and correct anti-replay mechanism break down to allowing replay over a number of seconds, rather than days (or longer).

Kyle

From: TLS [mailto:[email-masked]] On Behalf Of Colm MacCárthaigh
Sent: Sunday, May 21, 2017 10:29 PM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
- Clients MUST NOT use the same ticket multiple times for 0-RTT.

I think clients should duplicate them sometimes, just to keep servers on their toes ;-) this is what we talked about maybe being a grease thing .. if at all.

1. Requiring it.

I'm for requiring it, and for removing the stateless technique ... because it prevents the side-channel and DOS attacks and those seem like the most serious ones (and also, the new ones).

So far each case where we've thought "Actually stateless might be ok in this case" ... like the example of DNS ... turns out not to be safe when examined more closely (in DNSes case it would compromise privacy because caches could be probed).

--
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 22 May 2017 10:24:13 -0700

On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz <[email-masked]> wrote:

> The stateless technique certainly doesn’t solve all issues with replay.
> Neither do the other techniques, unless a fairly unrealistic (imo, in most
> use cases) retry strategy is used.
>

The stateless technique is insecure; plain and simple, and it is far more
easily exploited than issues that have caused us to deprecate cipher
suites. It should come out. It enables attacks that are materially
different from forced retries, such as cache probing and statistical
side-channel analysis.

> But the stateless technique is definitely an improvement over no
> anti-replay mechanism at all (for instance it reduces the possible number
> of rounds of a cache probing attack, assuming the cache TTL > replay
> window).
>

Today TLS has robust anti-replay; the comparison to "no anti-replay
mechanism at all" isn't relevant.

> Which mechanisms to use, and whether to enable 0-RTT in the first place
> (or PSK mode at all), should be decided considering the tradeoff between
> security/performance/implementation constraints, etc. In the case of DNS,
> most DNS security protocols (dnssec, etc.) do allow this kind of replay so
> I think it is a pretty reasonable tradeoff to consider.
>

This same argument could be made for keeping MD5, or RC4.  DNSSEC is not
concerned with secrecy. TLS is. This exact kind of replay would compromise
the secrecy of the data being transported.

> Additionally, I think the stateless technique is quite useful as a
> defense-in-depth mechanism.
>

It's tempting because it lowers the costs for implementors, but it's
absolutely not secure.  I seriously doubt that any application can be made
side-channel free in the manner that would be required to preserve secrecy.

> I highly doubt all deployments will end up correctly implementing a
> thorough anti-replay mechanism (whether accidentally or willfully).
>

This is why I think we should GREASE this and report (to users) any sites
that show any signs of replay tolerance.

> The stateless method is very cheap, and can be implemented entirely within
> a TLS library even in a distributed setup, only requiring access to an
> accurate clock. I’d much rather deployments without a robust and correct
> anti-replay mechanism break down to allowing replay over a number of
> seconds, rather than days (or longer).
>

I'd prefer if that were possible too, but it's not possible - it's
insecure.

-- 
Colm

---

From: Christian Huitema <[email-masked]>
Date: Mon, 22 May 2017 10:46:43 -0700

On 5/22/2017 10:24 AM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz <[email-masked]
> <mailto:[email-masked]>> wrote:
> ...
>
>     Which mechanisms to use, and whether to enable 0-RTT in the first
>     place (or PSK mode at all), should be decided considering the
>     tradeoff between security/performance/implementation constraints,
>     etc. In the case of DNS, most DNS security protocols (dnssec,
>     etc.) do allow this kind of replay so I think it is a pretty
>     reasonable tradeoff to consider.
>
>
>
> This same argument could be made for keeping MD5, or RC4.  DNSSEC is
> not concerned with secrecy. TLS is. This exact kind of replay would
> compromise the secrecy of the data being transported. 
>  
Check DKG's analysis of 0-RTT for DNS over TLS:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html.
There is only one point of concern, a minor privacy leak if the DNS
queries in the 0-RTT data can be replayed at intervals chosen by the
attacker. The idea is to replay the data to a resolver, and then observe
the queries going out to authoritative servers in clear text. The
correlation can be used to find out what domain the client was
attempting to resolve. The attack requires "chosen time" by the
attacker, and thus will probably be mitigated by a caching system that
prevents replays after a short interval.

-- Christian Huitema

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 22 May 2017 10:56:19 -0700

On Mon, May 22, 2017 at 10:46 AM, Christian Huitema <[email-masked]>
wrote
>
> Check DKG's analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail-
> archive/web/dns-privacy/current/msg01276.html. There is only one point of
> concern, a minor privacy leak if the DNS queries in the 0-RTT data can be
> replayed at intervals chosen by the attacker. The idea is to replay the
> data to a resolver, and then observe the queries going out to authoritative
> servers in clear text. The correlation can be used to find out what domain
> the client was attempting to resolve. The attack requires "chosen time" by
> the attacker, and thus will probably be mitigated by a caching system that

I have a reply to that too, linked at the bottom: there's actually a more
trivial side-channel (due to non-idempotence) that hadn't been considered
in the original analysis.

I've yet to find /any/ example application where 0-RTT replay would
actually be side-channel free.

-- 
Colm

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 May 2017 21:23:19 -0500

On 05/22/2017 12:56 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:46 AM, Christian Huitema
> <[email-masked] <mailto:[email-masked]>> wrote
>
>     https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_dns-2Dprivacy_current_msg01276.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=GpV0HuEr8VOZYeOaFgKwdKskI0x-DDWOnnYVY71gWo0&s=sIac6VMHVpaHv3FPdo-jIsOTEbAh8WPU01BhfV8CRcw&e=>.
>     There is only one point of concern, a minor privacy leak if the
>     DNS queries in the 0-RTT data can be replayed at intervals chosen
>     by the attacker. The idea is to replay the data to a resolver, and
>     then observe the queries going out to authoritative servers in
>     clear text. The correlation can be used to find out what domain
>     the client was attempting to resolve. The attack requires "chosen
>     time" by the attacker, and thus will probably be mitigated by a
>     caching system that prevents replays after a short interval.
>
>
>
> I have a reply to that too, linked at the bottom: there's actually a
> more trivial side-channel (due to non-idempotence) that hadn't been
> considered in the original analysis.
>

Sorry for being daft, but a direct link to this additional side-channel
would be helpful.

-Ben

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 22 May 2017 19:53:06 -0700

> Sorry for being daft, but a direct link to this additional side-channel

I should have done it the first time.  Here it is:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html

-- 
Colm

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 May 2017 09:52:57 -0700

On 5/22/2017 7:53 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Sorry for being daft, but a direct link to this additional
>     side-channel would be helpful.
>
>
> I should have done it the first time.  Here it
> is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html
>

Colm's point is that for many DNS servers, queries are not truly
stateless. The answer to a query for AAAA records for example.net might
vary over time, or even query to query, for example to manage load
balancing. Adversaries can predict these variations. They can observe
the state of the server before and after replaying 0-RTT data. If they
observed that the 0-RTT data caused the answer to change, they can
confirm that the 0-RTT data contained a request to that server.

I take that as an example of the more generic statement, that it is
really difficult to guarantee that transactions are really stateless.
Some transactions are apparently stateless, because the operation in
theory only reads data from the server. But even these transactions can
change the state of the server in subtle ways, such as servers managing
load balancing. Another example would be web servers rotating
advertisements on the page, which also can be observed. If I get Colm's
point correctly, he asserts that this is a fairly general pattern, and
that only fools can assume that a given transaction is "stateless".

I take that as a strong argument for requiring "at most once"
functionality for 0-RTT data.

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 May 2017 13:50:52 -0400

> On May 23, 2017, at 12:52 PM, Christian Huitema <[email-masked]> wrote:
> 
> Colm's point is that for many DNS servers, queries are not truly stateless. The answer to a query for AAAA records for example.net might vary over time, or even query to query, for example to manage load balancing. Adversaries can predict these variations. They can observe the state of the server before and after replaying 0-RTT data. If they observed that the 0-RTT data caused the answer to change, they can confirm that the 0-RTT data contained a request to that server.

The fix is to amend DNSpriv to require stateless (random rather
than say round-robit) RRset rotation.  With random rotation, the
next RRset order is independent of previous queries.

Secondly, even with the 0-RTT leak, while privacy against an active
attacker might not be assured for all users, there is fact privacy
for most users, especially against a purely passive adversary.

DNS privacy is always an imperfect security mechanism because
the DNS query will often at in the provider request to the
authoritative servers leak the user's "subnet" in the clear,
typically in the form of the containing /20 CIDR block to aid
load-balacing CDNs.  Then after the response is received, the
client will send IP datagrams that further narrow the set of
potential domains.  Then in visiting a website there'll be
unencrypted SNI, or predictable patter of response sizes and
consequent retrieval of CSS/javascript/image resources that
fingerprint the request.

Cryptography and 0-RTT are far from the weakest link in the
chain here.  DNSpriv is necessarily imperfect incremental
security, and defeating traffic analysis is exceedingly
difficult.

To the extent that DNSpriv over TLS happens at all, 0-RTT
will be used for DNS, and will be used statelessly (allowing
replays).  If there are sufficiently cheap ways to improve
security (e.g. random RRset rotation) without sacrifing
performance, increasing latency or adding complexity, then
by all means promote their adoption.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 23 May 2017 11:07:43 -0700

> next RRset order is independent of previous queries.

That's a good fix for that specific local problem. But next, consider a
different one; what if a DNS provider has q-tuple rate-limiting for DOS
attacks? That's not an unusual measure for large providers - even bind9 has
support for it. Well with stateless 0RTT I can replay the clients query
over and over until the rate-limiting trips; now I have a DOS attack *and*
a privacy-defeating attack; because the rate limit exposes what the query
was for.

> for most users, especially against a purely passive adversary.

My reference here isn't really meant as a criticism of DNSPriv - we should
make DNS private and secure, that's awesome, and it's a small attack in the
overall context of DNS. It's meant like Christian said; it is really really
hard to make an application protocol idempotent and side-effect free and
very smart people are often wrong about assuming that they are. I see
at-most-once 0-RTT mitigation as essential to avoiding a lot of real world
security issues here, because of that difficulty.

> replays).

That's not good for users, and seems like another very strong reason to
make it clear in the TLS draft that that it is not secure. FWIW; DNSCurve
includes nonces to avoid attacks like this:
https://dnscurve.org/replays.html (which means keeping state).

Stateless mechanisms simply aren't secure. We wish they were; because it is
so attractive operationally - just as it would be nice if my MD5
accelerators were still useful. But they don't hold up. We've even seen
this before with DTLS; where replay tolerance opened up the window to
several cryptographic attacks. It's an all-round bad idea.

I've seen a number of arguments here that essentially boil down to "We'd
like to keep it anyway, because it is so operationally convenient". Is that
really how this process works? Don't demonstrable real-world attacks
deserve deference?

-- 
Colm

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 May 2017 14:27:45 -0400

> On May 23, 2017, at 2:07 PM, Colm MacCárthaigh <[email-masked]> wrote:
> 
> That's not good for users, and seems like another very strong reason to make it clear in the TLS draft that that it is not secure. FWIW; DNSCurve includes nonces to avoid attacks like this: https://dnscurve.org/replays.html (which means keeping state).

Actually, nonces in DNScurve protect clients from replayed server responses (clients
are stateful).  I see no explicit guidance to detect or refuse replays of client
queries in DNScurve.  While servers could keep a nonce cache, in practice there
are multiple servers and they don't share state (no "strike registers").

The replays discussed in the URL you provide are replays of stale, but still
within signature validity DNSSEC server responses.  Not replays of requests.

-- 
	Viktor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 23 May 2017 11:38:47 -0700

> are multiple servers and they don't share state (no "strike registers").

My apologies, you're right! I'll make sure to tease djb now. That's still
an insecure design (or at least a privacy defeating design) for the same
reasons as earlier. Though tinydns doesn't do RRL or Cyclic answers, so in
that coupled implementation it may be ok.

At one time we didn't think the kinds of side-channels present in TLS were
a big deal; the "it is not believed to be large enough to be exploitable" note
in section 6.2.3.2 of RFC5246 comes to mind. Here we risk repeating history.

-- 
Colm

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 May 2017 14:22:29 -0500

On 05/23/2017 01:07 PM, Colm MacCárthaigh wrote:
>
> I've seen a number of arguments here that essentially boil down to
> "We'd like to keep it anyway, because it is so operationally
> convenient". Is that really how this process works? Don't demonstrable
> real-world attacks deserve deference?

The process is more like "once the participants have gotten used to an
idea, it takes some time to digest countervailing reasoning when
potentially subtle issues are involved".  Without yet taking a position
myself, it seems like at least some folks are coming around to see your
position, and the dialogue should continue.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 May 2017 19:32:54 +0000

>I've seen a number of arguments here that essentially boil down to "We'd like to keep it anyway, because it is so operationally convenient". Is that really how this process works? Don't demonstrable real-world attacks deserve deference?

Well it's a little more subtle then that; folks seem to acknowledge the attacks but feel that their use-cases won't be affected.  I'm looking at you, Chrome, boring, Firefox :)

Don't get discouraged.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 May 2017 20:00:58 +0000

> Well it's a little more subtle then that; folks seem to acknowledge the attacks
> but feel that their use-cases won't be affected.  I'm looking at you, Chrome,
> boring, Firefox :)

I've heard from two people that the "looking at you" phrase was not well-received.  I apologize to the list, and those whose feelings I hurt.  I look forward to seeing more detailed responses to Colm's posts soon.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 May 2017 18:15:37 -0500

> the path (e.g. CDNs in HTTP are in general invisible to the client).

I think the attacker has to delay sending the client's 0-RTT to the
middlebox for the 10-second window if it wants to get the 20-second
delay overall (assuming the middlebox does at-most-once properly), at
which point the client would have a sense that something fishy might be
going on.  Though, that still doesn't give the client a hard bound on
the delay, I suppose.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 May 2017 08:50:07 -0500

On 05/21/2017 05:47 PM, Eric Rescorla wrote:
>
>
> On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara
> <[email-masked] <mailto:[email-masked]>> wrote:
>

I think it's just an attempt to make clear what the client behavior
should be.  It's like when we say that implementations MUST NOT put more
than one extension of the same type in a given extension block.  The
peer has to validate received messages, but the local implementation has
to know to not generate them, either.

>     - Servers MAY accept the same ticket multiple times.

It seems implicit to me, as well, though I'm not sure that there's harm
in saying it explicitly, particularly when reusing a ticket is a MUST
NOT in certain specific cases (0-RTT).

> down on mass replays, though it would of course still make

Right, this would bring replays down from the millions hypothesized for
the weak time-based thing to more like tens, which is kind of in the
regime that we are currently in with (at least some) application behavior.

> interested in hearing from others in the WG what they think about:

I think it's worth writing up the most-secure scheme(s) we know of, to
give us some concrete text to digest and decide if we can live with.

> 2. Whether they still want to retain the stateless technique.

If we think we can require it and have it actually stick, that seems
like the safest plan.  The results of this discussion leave me uneasy
with a scheme that permits millions of replays, even if there is not
something concrete that I definitely object to.  As DKG (almost) said,
"we're designing a security protocol, not an easy-to-implement
protocol".  I'm still concerned that if we put MUST it will be more RFC
6919 than 2119, though, even if clients and/or ssllabs try to grease
it.  So, if we require it, then the stateless technique is not needed
per se (but we still want the time limit so as to bound the size of a
strike register).  If we don't/can't require it, then I would say keep
the stateless technique but try to crank down the time window and
suggest that implementations rate-limit 0-RTT acceptance per domain to
try to get away from the billions of replay regime.

Another crazy idea would be to just say that servers MUST limit the use
of a single binder to at most 100 times, with the usual case being just
once, to allow for alternative designs that have weaker distributed
consensus requirements (but still describe these current two methods as
examples of ways to do so).

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 May 2017 17:30:42 +0300

> to know to not generate them, either.

There's also quite a bit of difference between:

- MUST NOT do X
- MUST NOT do X, MUST abort with Y if X is done.

As the second requires receiver to detect X, which can be hard. E.g.,
detecting arbitrary duplicated extension is definitely not trivial.
 
E.g., for duplicate extensions, my implementation only validates the
known extensions. As consequence, unknown extensions in offers can
appear multiple times without detection (e.g., two copies of extension
35 in ClientHello). It is done that way to limit resource usage:
Checking a small list of extensions is easy, checking 64k of those is
less so.

> regime that we are currently in with (at least some) application behavior.

Actually, even tens of replays at TLS level is quite dangerous,
especially if to different servers (bad information leaks via cache
attacks).

> give us some concrete text to digest and decide if we can live with.

However, every scheme that isn't the most-secure (tied 1st place) that
has been proposed so far is too insecure.

> protocol". 

There is major difference about how hard TLS 1.3 is to _implement_, and
how hard it is to _use_.

Most serious TLS 1.3 implementations will be written by experts.
Additionally, the protocol avoids using constructs that are almost
impossible to implement properly (e.g., good riddance TLS blockmode).

Whereas most applications using TLS will not be written by security
experts. And the protocols they implement are not designed for side-
channel resistance in implementations.

> examples of ways to do so).

You actually need strong distributed consensus about all accepted
0-RTT here.

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 24 May 2017 08:32:34 -0700

> especially if to different servers (bad information leaks via cache

It hard stops replays, but does nothing about retries, and I think that's
ok. The client is in much more control of retries, and it's similar (if not
identical) to what can happen today with an interrupted TCP or TLS
connection. If a client permits hundreds, or millions of forced retries, I
think that's more appropriately handled at the client/application level,
but keep in mind there are typically seconds between the retries and the
rate of attack is slow.

Replays are when an attacker can send the same data at-will and it's
completely unknown to the client, it can happen out of band over different
network connectivity, in a very short and sharp interval of time, possibly
even to different server endpoints, and can be used by attackers to gather
information. These I think need to be mitigated at the TLS level; and
should be hard-stopped.

> You actually need strong distributed consensus about all accepted

This pattern doesn't need strong consensus. If you have 10 servers, you
could give each 10 goes at the ticket, and let each exhaust its 10 attempts
without any coordination or consensus. You likely won't get to "exactly
100", but you will get to "at most 100 times".

But the inner critical section would be inherently more complicated.  For
the at most once case we need to a critical section that performs an
exclusive-read-and-delete atomically. It's a mutex lock or a clever
construction of atomic instructions.  For "at most N" we now need to
perform a decrement and write in the critical section, and it becomes more
like a semaphore.

It's probably not a pattern that's worth the trade-offs.

-- 
Colm

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 May 2017 12:04:38 -0500

On 05/24/2017 10:32 AM, Colm MacCárthaigh wrote:
> This pattern doesn't need strong consensus. If you have 10 servers,
> you could give each 10 goes at the ticket, and let each exhaust its 10
> attempts without any coordination or consensus. You likely won't get
> to "exactly 100", but you will get to "at most 100 times". 
>

Or (up to) 100 servers and give each server just one crack at the
ticket, which is perhaps more plausible to implement sanely.

> But the inner critical section would be inherently more complicated. 
> For the at most once case we need to a critical section that performs
> an exclusive-read-and-delete atomically. It's a mutex lock or a clever
> perform a decrement and write in the critical section, and it becomes
> more like a semaphore. 
>

That particular decrement-based design is not worth the trade-off,
definitely, but I doubt it's the only scheme that could meet the stated
requirement.  Something that attempts to access a global single-use data
structure but has some failure tolerance for that operation, and some
plausible story for bounding how often that can happen, say (like
stopping accepting 0-RTT at all on that server for 10 seconds once a
threshold level of errors occurs).

But, as indicated by the "crazy idea" prefix, I am not actually pushing
for this scheme.

-Ben

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 30 May 2017 17:38:02 -0400

Hi Colm,

Thank you for your analysis!  I appreciate the attention to the security
properties of the 0-RTT requests, as it is the more delicate part of the
protocol.  It took me a while to get through the entire review, and there
are
many things on which I would like to comment, but if I do that for every
one of
them, this reply would be too long.  Hence, I’ll try to concentrate on the
key
points.

1) The security of a system is an end-to-end property.

TLS isn’t a magical “transport security solution”, it provides a very
specific
set of explicit security guarantees to the applications that use it.  It
can be
used as a building block for the secure systems, but at the end of the day,
the
security of a system hinges on the designers’ understanding of the security
contracts provided by individual components.

TLS 1.3 as-is does not remove any of the replay protection guarantees
provided
by TLS 1.2.  However, if the user chooses to waive said protection in order
to
do 0-RTT, they can do that with an API explicitly designed for that purpose.

What I believe is important here is that we are very explicit about the
security
guarantees the application is expected to get from TLS.  PR#1005 currently
does
not answer this question in a satisfying manner, since it says that the
server
SHOULD implement three different mechanisms with very different
properties.  If
we provide any replay protection at all, it needs to be well-defined as a
security property.  That is,

2) We have to define explicitly what security properties TLS 0-RTT has.

There are two obvious levels of protection we can provide:

 A. No protection.  Applications are expected to handle idempotency
themselves,
    which is something they already probably should be doing anyways.

 B. Full protection.  Applications can rely on the assumption that once
data is
    written to TLS stack, it will arrive to the receiver at most once, and
TLS
    will enforce that even in presence of passive and active attackers on
the
    path.

I think all of us agree is that we should go for level B if we can have
it.  The
“if” here is important, since...

3) Full replay protection for 0-RTT is not realistically feasible at TLS
layer,
   because TLS layer is not the right place for that.

You’ve already pointed out the existence of the DKG attack, where the
attacker
forces the client to retry the request with 1-RTT.  In this scenario, the
attacker has a buffered 0-RTT request and is ready to insert it at any
convenient point in time, violating the initial order assumptions.

There is also a wide variety of cases in which a web browser or an HTTP
proxy
can be induced to retry a request, with mechanism often as simple as a TCP
RST.
Even if browser will refuse to do that, most users will “reload” themselves.
This is why the applications *need* to protect against replays end-to-end --
asking users to roll back an extra $1000 transaction is not actually
acceptable.

With respect to the non-browser HTTP applications, I am not sure I am sold
on
the notion of “careful clients”.  My understanding is that you suggest to
treat
0-RTT failure as semantically equivalent to a regular connection failure,
under
the assumption that all of your clients already have to handle that case
properly.  I see how this is supposed to work out, but most systems of this
nature work well because connections succeed most of the time -- and as you
go
more and more towards the path of promising full replay protection, you will
break more and more 0-RTT handshakes.  Both session resumption in general
and
0-RTT in particular are designed with assumption that they can be declined
at
any point, that this is a normal and expected event, and at worst it would
result in a minor performance degradation; “careful clients” violate that
assumption.

As for the non-HTTP applications, that would have to be determined by their
respective application profiles, but I suspect they are going to be less
complex.  For example, I expect 0-RTT for SMTP to be as simple as just
sending
“EHLO mail.example.org\n”, which can be replayed regardless.

My key point here is that the problem of protecting against duplicate
messages
in a system is sufficiently complex that it can only be reliably solved
end-to-end.

(In fact, the original End-to-End Argument paper also considers that case:
“if
the application level has to have a duplicate-suppressing mechanism anyway,
that
mechanism can also suppress any duplicates generated inside the
communication
network, so the function can be omitted from that lower level.” [Saltzer et
al.,
1981] -- here, I suggest to think of the “communication network” as the
system
of HTTP-layer boxes and middleware that modern systems are made of.)

------------

So, I hope we can agree that we cannot really guarantee B.  There is
another,
third level of protection that surprisingly is worth considering:

  C. “Nebulous” replay bound.  0-RTT data can be replayed, but only for some
      finitely bounded number of times.  I initially wanted to call this
“weak
      replay protection”, but that felt too generous.

Normally I would dismiss this as a useful security property due to its
inherent
vagueness, for the same reasons that “your server is too far away for
nanosecond-level timing attacks on Intel CPUs” is a property that no serious
cryptographer would admit in a research paper.  However, you’ve pointed out
some
interesting side channel leaks, which exist even without 0-RTT, but can be
amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is
a
meaningful property to provide.

Let’s talk about what mechanisms are and are not viable for the nebulous
bound
promise.

4) Operational experience on datacenter-local strike registers is negative.

We deployed strike registers in the initial QUIC deployment, and it was an
operational hassle, so once we discovered that they do not provide full
replay
protection (due to all issues outlined above), the cost/benefit analysis
became
decidedly not in their favor.

Our deployment experience also suggests that the negative impact from
limiting
0-RTT to the same datacenter is not negligible.

I feel like you are underestimating the cost and complexity of the
distributed
solutions proposed:
 - RAM might be cheap in a big datacenter, but on a CDN node, the
opportunity
   cost of not using that RAM for something else is higher.
 - There is nothing simple about running distributed storage, given that on
top
   of usual operational requirements (ability to rescale and some degree of
   fault tolerance), you also require an atomic read-and-delete.
 - Strike registers with strong guarantees are probably even worse in that
   regard, since inserting a strike record requires a consistent write.

5) Nebulous replay bounds are possible but very much deployment-dependant.

If your deployment consists of one server that can accept a given ticket,
you
can just run a single strike register in memory.  Not particularly painful,
and
solves the problem for simple deployments.

If you wish to accept tickets across multiple servers, to improve 0-RTT
rate,
now we have the tension between wanting cross-server 0-RTT and avoiding
distributed cross-server state. But if your servers are individually
addressable, we can put the client-presumed server IP into the ClientHello
and
use machine-local strike registers. Servers decline 0-RTT if the
client-supplied
IP does not match.  This gives us global replay protection without the need
to
share state.

If you are using QUIC, any of your IPs is terminated by the same load
balancer,
and the load balancers use connection ID to pick the backend, you will also
normally arrive at the same TLS server provided that the server pool was not
resharded.  At that point, local strike register is sufficient; in fact, if
you
have a time-wait list, you get it almost for free.

Of course, this all relies on resumption arriving to the same server as the
original request.  This is obviously not a property you want in a
large-scale
reliable systems, so as soon as you introduce anycast IP addresses or load
balancing based on parameters that are not bound cryptographically, you’ll
need
a strike register of a scope larger than a machine, so you have to either
make
one (since we only promising nebulous bounds, this can be eventually
consistent).  Or you could just settle for server-local strike registers --
since we’ve already decided that the bounds are nebulous, and I see no
point of
haggling on how many replays is too many.

I feel like the topic of “how do I make the lowest nebulous replay bound
with
the lowest amount of effort” is very large on its own, and is honestly not
that
important for the protocol design.  The client’s ability to specify the
presumed
server’s IP address is nice, and it would require a new extension in the
specification itself, but that would be as far as I would go.  What’s
important
is that we can require implementations to provide nebulous bounds.  We of
course
should, on top of that, require clients and endorse servers to enforce the
application-level requirements on idempotence.

------------

Specific proposals I would like to make for TLS 1.3 draft based on the
discussion above:
 1. Emphasize that 0-RTT data is fundamentally replayable, and can be
replayed
    by the attacker at a convenient point.
 2. Replace the current suggestion to use specific mechanisms with a generic
    requirement to provide the “nebulous bound” for replays (terminology up
to
    your preference).
 3. Leave the exact details of how said bound is achieved up to the
    implementations, but point out that time-based replay protection is not
    sufficient.  It might be worth to keep the current discussion of
particular
    mechanisms as an appendix.
 4. Add a “server IP” extension to the 0-RTT ClientHello, while we are at
it.

  -- Victor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 30 May 2017 18:32:22 -0400

On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote:
> TLS isn’t a magical “transport security solution”, it provides a very specific
> set of explicit security guarantees to the applications that use it.  It can be
> used as a building block for the secure systems, but at the end of the day, the
> TLS 1.3 as-is does not remove any of the replay protection guarantees provided
> by TLS 1.2.  However, if the user chooses to waive said protection in order to

+1; In fact, I'd suggest sticking this almost as-is into the spec somewhere.

>       finitely bounded number of times.  I initially wanted to call this “weak
> Normally I would dismiss this as a useful security property due to its inherent
> cryptographer would admit in a research paper.  However, you’ve pointed out some
> amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is a
> bound promise.

There is one relatively straightforward mechanism for limiting 3rd party replay:
A 3rd party replaying 0-RTT PSK will fail to successfully complete the handshake
(after 1-RTT), as it would generally have the identity/ticket but not the key
behind it (e.g. resumption_master_secret). The 0-RTT data will have already been
processed, however a server detecting any PSK failure could then flag the
offending ticket/IP and reject all future 0-RTT attempts for some time period (e.g.
ticket lifetime). This would limit replays to one per server, or less if this banned
0-RTT state is shared across servers. The notable problem with this mechanism
is that a 0-RTT DDoS, could easily balloon the state size rather significantly, if not
careful. Servers would have to be fine with budgeting resources for a nontrivial
state in the event of attack, even if they don't need it during normal operation,
but that could at least be doable. A replay from the 1st party that is expected to
have the correct key/secret or from a 3rd party that has stolen it would not be
mitigated by this system, but that's much harder for an attacker to attempt, at
least.

Dave

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 30 May 2017 18:56:16 -0700

> them, this reply would be too long.  Hence, I’ll try to concentrate on the

Thanks too for reading and the response!

> do 0-RTT, they can do that with an API explicitly designed for that

I don't think this holds true;  the signs are that browsers and servers
will enable by default, with well-meaning limits on the kinds of requests.
But in the real-world; it'll absolutely be enabled lots, that's the point
after all. I hope we can have pervasive 0-RTT. It'll be awesome, because
the speed of light sucks.

> convenient point in time, violating the initial order assumptions.

Yep, though as I point out too, I think the DKG attack is different from
other replay attacks in ways that matter. The only place that the DKG
attack can be mitigated is at application layer. The TLS APIs and different
streams are pointless here. And I think that's actually an ok trade-off for
some kinds of applications - I don't think it should be a blocker for
0-RTT.  I think we agree on all this.

> nature work well because connections succeed most of the time -- and as
> you go

The careful client is just to illustrate what it takes to make a
replay-safe application on top of an eventually consistent data store model
(which isn't uncommon) ... I don't think it's that realistic either, but it
was to point out that separate streams don't help. Only timings do.

> decidedly not in their favor.

The argument about operational inconvenience is irrelevant and dangerous.
It doesn't matter that it's hard. It doesn't matter how much it costs. It's
the cost of doing 0-RTT securely. Doing it insecurely should not be an
option, and shouldn't be something specified in an RFC.

> 0-RTT to the same datacenter is not negligible.

This is the terribly false premise that gets to the heart of things. You
acknowledge yourself that there are attacks. Here you argue, essentially,
that it is too inconvenient to mitigate those attacks for users. I don't
think we can seriously take that approach.

If the methods are too inconvenient, the secure alternative is to not use
0-RTT at all.

The key phrase here "the negative impact from limiting 0-RTT to the same
datacenter is not negligible" is simply utterly the wrong way around. Yes,
it's true that fewer 0-RTT sections are accepted in a datacenter-local
system than if they are globally valid; but globally valid ones are not
secure; so what's the benefit of that comparison? It's not an alternative
we can responsibly consider. The only secure comparison is to not having
0-RTT at all. At least with datacenter local 0-RTT we do get /some/ 0-RTT.

So the statement should really be "Datacenter-local 0-RTT resumption allows
us to use 0-RTT at all, which is great, considering that it would otherwise
lead to side-channel and privacy-defeating attacks. What a sad world that
would be".

It's not useful to compare secure approaches to insecure ones, we can only
consider the former. AES-GCM is a lot slower and more expensive than RC4,
but I still have to use it.

>  - There is nothing simple about running distributed storage, given that
> on top

These really suck, I agree. This is why it's so vitally important that we
agree that 0-RTT sections "MUST" be non-replayable, precisely because this
false line of logic is so mentally tempting. And because a set of providers
may be willing to make the insecure trade-off, and risk creating a "race to
the bottom" that means all deployments end up with  these insecure
configurations.

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 31 May 2017 12:48:50 +0300

On Tue, May 30, 2017 at 05:38:02PM -0400, Victor Vasiliev wrote:

<Snip long message>

A couple points:

- Various mechanisms related to conserving IPv4 addresses can result
  client and server disagreeing about server IP address. Or even the
  address family.
- If one has limited number of replays, distributing those among
  multiple servers is the most dangerous.
- If you rely on sticky loadbalancer, you have to ensure that attacker
  can't send requests directly to the servers, bypassing the
  loadbalancer! In some architectures, it is rather easy to
  accidentially expose the backend servers, even if all the honest
  connections flow through the loadbalancer.
- Binders are computationally random, so if you want to shard on
  those for strike register, simple mod N scheme distributes the load
  well.
- 0-RTT scope can be written into tickets. The session ticket scope
  may be larger than that. Routing to datacenters should be relatively
  sticky.
- As noted, this mess with state is just necressary for security if
  you use 0-RTT.
- Could be good idea for clients to blacklist origins for tickets
  (meaning, use GDHE-CERT and possibly (GDHE-)static-PSK handshakes
  only) for some time if duplicate accepts are detected during
  grease testing. That should not cause any servers to actually
  break from user standpoint, since servers need to support those
  handshake modes anyway.

-Ilari

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 31 May 2017 15:49:03 -0400

On Tue, May 30, 2017 at 9:56 PM, Colm MacCárthaigh <[email-masked]>
 wrote:

> Here you argue, essentially, that it is too inconvenient to mitigate those
> attacks for users. I don't think we can seriously take that approach.
>
> [snip]

I think I am not getting my key point across here clearly.  I am not arguing
that they are inconvenient, I am arguing that the guarantee you are trying
to
provide is impossible.

I wholeheartedly agree that if it is possible to provide guarantee B (zero
replays), we really should provide it.  The problem is, we cannot.  Since
0-RTT
is by its very design declinable, there will be always a possibility for at
least one retry.

Once you concede you can have at least one replay, the difference between
one
replay and N replays (for all N > 0) is not that large, which is why I
refer to
this as "nebulous bound" (guarantee C).  Your applications already have to
contend with replays, it's now just the matter of preventing side-channel
amplification.

So, in other words, since we're now just bargaining about the value of N,
operational concerns are a fair game.

> the speed of light sucks.

To clarify, I am not suggesting that two streams would help.  I completely
agree with you that two streams is not going to mitigate the DKG attack or
others.  What I meant is that 0-RTT inherently has slightly different
properties from 1-RTT and must be used with that in mind.  Specifically, I
meant that it will not be enabled for applications by default, and HTTP
clients
would only allow it for methods that RFC 7231 defines as safe.

> other replay attacks in ways that matter.
>

I do not believe that this to be the case.  The DKG attack is an attack
that allows
for a replay.  There is an enormous difference between a protocol that does
not
allow replays and the protocol that allows one.  For many applications, it
only
takes one replay for things to go terribly wrong.

> The only place that the DKG attack can be mitigated is at application
> layer.
>

Indeed.

> The TLS APIs and different streams are pointless here.
>

I agree that different streams are pointless.  The only ways APIs can help
is
to not send replay-sensitive requests via 0-RTT, and to not accept those
requests until peer liveness is confirmed.

> And I think that's actually an ok trade-off for some kinds of applications
> - I don't think it should be a blocker for 0-RTT.  I think we agree on all
> this.
>

I don't think this is an okay trade-off for any application that changes
state
-- in particular, I am strongly against sending POST requests over 0-RTT.
I do
agree, however, that ability to replay requests some bounded number of times
should not preclude us from deploying 0-RTT.

> [snip]
>
> You acknowledge yourself that there are attacks.
>

Indeed, but I am not suggesting we ignore those attacks.  The way I see
this is
that, originally when we did 0-RTT in QUIC, we had strike registers which
are
approximately what you are advocating.  We thought this provided property B
(at-most-once semantics for 0-RTT), but at the IETF, people discovered the
DKG
attack.  Strike registers do not provide B and in fact B is impossible to
provide at the TLS layer.  Thus TLS 1.3 went towards A (no replay
protection at
all for 0-RTT), as it's simpler and we didn't have B anyway.

But, as you describe, this enables some interesting side channels. Now,
these
side channels exist even without 0-RTT.  Attackers already can measure
response
times, probe and groom caches, direct traffic, etc.  *But*, with unlimited
0-RTT replay, the attacker can repeat the experiment unboundedly and amplify
the side channel.

Thus, A is problematic.  I think we both believe this and both agree then
that
the current text is unsatisfactory.  So the question is what to replace it
with.  Whatever we provide, it should be a clear security guarantee between
the
application and TLS (depending on what guarantee we chose, some of your
other
attacks may or may not just be invalid uses of TLS).  B is obviously
preferable, but as it is impossible per DKG, I think we should set the
contract
at C (bounded replay protection).  This is a guarantee that is not
fundamentally impossible and also successfully mitigates your side channel
amplification attacks.

  -- Victor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 31 May 2017 13:52:00 -0700

> is by its very design declinable, there will be always a possibility for at

This is the part we agree on; but as I've said before, the kinds of attacks
enabled by these kinds of client-initiated retries, and by
attacker-initiated replays are fundamentally different.

> this as "nebulous bound" (guarantee C).
>

There's a very big difference and it leads to real-world attacks. With many
replays, all sorts of side-channel analyses become possible, and I've
provided examples. It's particularly nasty that the replays can be
out-of-bound and to arbitrary nodes of the attacker's choosing, which makes
the attacks even more effective.

> Your applications already have to

Yes; applications using 0-RTT do have to make themselves retry-tolerant,
 as they already must in many scenarios (e.g. a browser driven
application).  What concerns me most here is that people are clearly being
confused by the TLS 1.3 draft into mis-understanding how this interacts
with 0-RTT. For example the X-header trick, to derive an idempotency token
from the binder, that one experimental deployment innovated doesn't
actually work because it doesn't protect against the DKG attack. We're
walking into rakes here.

> operational concerns are a fair game.

They're still not fair game imo, because there's a big difference between
permitting exactly
one duplicate, associated with a client-driven retry, and permitting huge
volumes of replays. They enable different kinds of attacks.

I keep forgetting about forward secrecy in all of this, but it's worth
noting that your argument for globally resumable sessions also implies that
we shouldn't really shoot for  FS for some of the most critical user data.
I also find that bizarre.

> would only allow it for methods that RFC 7231 defines as safe.

Well in the real world, I think it'll be pervasive, and I even think it
/should/ be. We should make 0-RTT that safe and remove the sharp edges.

> for a replay.

It's not. It permits a retry. The difference here is that the client is in
full control. It can decide to delay, to change a unique request ID, or
even not to retry at all. But the legitimate client generated the first
attempt, it can be signaled that it wasn't accepted, and then it generates
the second attempt. If it really really needs to it can even reason about
the complicated semantics of the earlier request being possibly
re-submitted later by an attacker.

Replays are different though; the attacker just literally copies the data
and can resend and resend as desired. As I've shown; this breaks real-world
things like authenticated throttling systems, and leads to side-channel and
cache analysis; where only very rarely is one attempt sufficient to
exploit.

> There is an enormous difference between a protocol that does not

This puts a massive smile on my face :)

> approximately what you are advocating.
>

Well I'd really advocate for single-use caches, because I think Forward
Secrecy is important :)

> We thought this provided property B

I think in retrospect this was rash :(

> 0-RTT replay, the attacker can repeat the experiment unboundedly and

Exactly :) but also ... what about the attack on the throttling
infrastructure? or other resource exhaustion? 0-RTT replay seems like a
really big problem here and it seems like the most realistic kind of attack
too; booters and trouble-makers trying to lock each other out of systems.

> with.  Whatever we provide, it should be a clear security guarantee
> between the

I'm all for bounded replay protection, with the bounds being 1 ;-)

-- 
Colm

---

From: Bill Cox <[email-masked]>
Date: Wed, 31 May 2017 15:42:07 -0700

I've looked at this issue from how this interacts with token binding.  The
layer above TLS (not quite what I would call the application layer) has to
know about the failed 0-RTT attempt so that it can update the token binding
headers in the HTTP request for the 1-RTT retry.  In particular, I want to
emulate a real proof-of-possession, which implies two things: uniqueness
and freshness of the signature.  With a single use cache, we can actually
ensure that the signature is unique, even with the DKG attack: the first
0-RTT flight and the second 1-RTT flight must contain unique TB signatures
in the TB headers.  The TB signature is non-replayable against servers
using 1-use caches.  We unfortunately still lack freshness, but I compare
this to the case of a session that never closed over the same period of
time.  Only one signature is required for this connection, which means the
signature is as stale as the connection.  I find it hard to justify the
need fore more freshness given this trade-off has already been made for
TB.  Uniqueness, however, is something that would be difficult to give up,
if we are to have TB at all for 0-RTT.

Traditional session caches are cheaper to build and maintain than strike
registers by a factor of several, for various reasons.  I feel strongly
that the default behavior of popular HTTP servers, when 0-RTT is enabled,
should be to enforce replay protection with a 1-use cache.  I would prefer
that the RFC wording be chosen to support this outcome.

Finally, it doesn't really make much difference whether we say that clients
SHOULD or MUST use replay mitigation with 0-RTT.  Corporations often choose
to ignore MUST and treat it like SHOULD.  The EMS RFC is a great example.
If we took MUST seriously, the EMS spec would break the web.  No one,
SFAIK, implemented all of EMS's MUST clauses.  The Code is more what you
call guidelines, than actual rules.

Bill