Subject: [TLS] Closing on 0-RTT

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 Jun 2017 16:18:03 +0100

Hi folks,

We've had a phenomenal amount of discussion around 0-RTT anti-replay,
and based on my recent summary e-mails I think we generally agree
about the technical facts, so it's time to finalize the PR and land it
in the specification.

Here's what I propose to do:

- Describe the attacks that Colm described.

- Distinguish between replay and retransmission

- Mandate (SHOULD-level) that servers do some sort of bounded
  (at-most-N times) anti-replay mechanism and emphasize that
  implementations that forbid replays entirely (only allowing
  retransmission) are superior.

- Describe the stateless mechanism as a recommended behavior but not
  as a substitute for the other mechanisms. As Martin Thomson has
  pointed out, it's a nice pre-filter for either of these other
  mechanisms.

- Clarify the behavior you need to get PFS.

- Require (MUST) that clients only send and servers only accept "safe"
  requests in 0-RTT, but allow implementations to determine what is
  safe.

Note: there's been a lot of debate about exactly where this stuff
should go in the document and how it should be phrased.  I think these
are editorial questions and so largely my discretion.

Here's what I do not intend to do.

- Mandate (MUST-level) any anti-replay mechanism. I do not believe
  there is any WG consensus for this.

- Design a mechanism to allow the server to tell the client that it
  either (a) enforces strong anti-replay or (b) deletes PSKs after
  first use. Either of these seem like OK ideas, but they can be added
  to NST as extensions at some future time, and I haven't seen a lot
  of evidence that existing clients would consume these.

I recognize that nobody will be entirely happy with this, but I
believe it most closely represents consensus. Assuming the chairs
agree, I'd like to suggest a brief period of discussion on this
proposal, followed by a consensus call, and then I'll generate a PR
that enacts it. People will still have time to review that, but in
order to avoid an endless round of dicussion, the idea will be able to
review it for conformance to these principles, not to re-litigate
these.

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Jun 2017 14:40:02 -0400

> Here's what I propose to do:
[...]
>   retransmission) are superior.
[...]
> Here's what I do not intend to do.
[...]
>   there is any WG consensus for this.

Whilst bounded replay protection isn't ideal, I wasn't aware of it being opposed to the point where we couldn't make it the bare minimum. There really needs to be some floor to the mess here.

If I've followed all of the discussion accurately, there may be a rough consensus that mandating with a MUST-level _some_ kind of anti-replay mechanism which MAY be implemented at the application layer as appropriate. (with a SHOULD-level requirement that it be done in the TLS implementation; MUST-level if we can actually agree to mandate bounded as a minimum, with better handling at the application level) In other words, either the TLS implementation MUST have replay protection or the application protocol profile MUST have its own replay protection (instead, or preferably in addition to a bare minimum). Replay protection would be required by TLS, but could be delegated to the application; people that want to do really unsafe stuff can define its replay handling mechanics there. This (heavily qualified) set of requirements would define TLS to be safe, so long as people stay within the known bounds laid out by the spec and profile(s) (with the potential for dubious profiles hand waved away...).

Dave

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 12 Jun 2017 11:12:27 -0700

> are editorial questions and so largely my discretion.

First of all, thanks for doing this, that all sounds great! The TLS spec is
obviously monumentally important to the internet, and years of hard work
aren't made easier by late-coming changes, that shouldn't be thankless.

>   there is any WG consensus for this.

The one case here where I'd really argue for a "MUST" is middle-boxes like
CDNs. The concern I have is if someone has an application that uses
throttling or is vulnerable to a resource-exhaustion problem and goes and
puts a CDN in front of it, it's not obvious that enabling TLS 1.3 could
open them to a new kind of DOS attack.

We've already seen CDNs enable TLS 1.3 with unintentionally broken 0-RTT
mitigations, so that's clear evidence that the existing guidance isn't
sufficient. I think it would help manage the interoperability risks if we
can point out to their customers that the configuration is unambiguously
broken. Or at least, it helps to flag it as a security issue, which makes
it more likely to get fixed. Absent this, the operators of "backend"
applications would have to live with risk that is created by the upstream
CDN providers for their own convenience. That seems like a really bad
interoperability set up.

I'd argue for at-most-once protection here, since that's the only way a
client can make deterministic decisions, and it's also easier to audit and
GREASE. But there doesn't seem to be consensus around that. At the moment,
I feel that's a bit like the lack of consensus the "Clean coal" industry
has on global warming though, because it seems to be an argument rooted in
operational convenience rather than actual security. This is not the
standard we apply in other cases; we wouldn't listen to those who say that
it's ok to keep RC4 or MD5 in the standard because the problems are small
and the operational performance benefit is worth it. My spidey-sense is
that these attacks will get better and more refined over time.

Nevertheless, /some/ guaranteed replay protection would be better than
none. particularly in this case. So if it's at-most-N, and N is small
enough to at least avoid many throttling cases, that's something worth
taking, even though it does leave open the easier cache-analysis attacks.

>   of evidence that existing clients would consume these.

This can happen totally outside of the protocol too; as-in an operator can
advertise it as a feature. Likely most useful for the forward secrecy case.

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jun 2017 18:19:25 +0000

> The one case here where I'd really argue for a "MUST" is middle-boxes like CDNs. The concern I have is if someone has an application that uses throttling or is vulnerable to a resource-exhaustion problem and goes and puts a CDN in front of it, it's not obvious that enabling TLS 1.3 could open them to a new kind of DOS attack. 

A CDN is not a middle box.  It *is* origin as far as the end-users are concerned, because of the business relationship between the CDN and the content provider.  Or, if you don't like that reasoning, then it's not a middlebox as the IETF uses the term.

If the intermediary is vulnerable to the resource attacks, that's the intermediary's issue.

> We've already seen CDNs enable TLS 1.3 with unintentionally broken 0-RTT mitigations, so that's clear evidence that the existing guidance isn't sufficient. I think it would help manage the interoperability risks if we can point out to their customers that the configuration is unambiguously broken. Or at least, it helps to flag it as a security issue, which makes it more likely to get fixed. Absent this, the operators of "backend" applications would have to live with risk that is created by the upstream CDN providers for their own convenience. That seems like a really bad interoperability set up.  

I agree with this.  Which is why I prefer separate streams for early data, and some kind of signaling to the content provider that is clear and unambiguous.  I don't know how to do that when, say, the intermediary/CDN has a persistent connection to the backend...

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 12 Jun 2017 11:30:33 -0700

On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich <[email-masked]> wrote:

> > The one case here where I'd really argue for a "MUST" is middle-boxes
> like CDNs. The concern I have is if someone has an application that uses
> A CDN is not a middle box.  It *is* origin as far as the end-users are
> concerned, because of the business relationship between the CDN and the
> content provider.  Or, if you don't like that reasoning, then it's not a
> middlebox as the IETF uses the term.
>

[ Browser ] <----> [ CDN ] <----> [ Origin ]

Sorry - I'm not trying to be inflammatory here, it's just a descriptive
term. All I mean is that the CDN is a box in the middle, as in that
diagram.  Here's what I imagine:

* Operator A operates the origin, and they incorporate throttling as a
routine security feature.
* Operator B operates the CDN, and they offer TLS 1.3 as a feature, without
replay protection.
* Customer enables TLS 1.3 on the CDN, because they want the speed benefit.
Seems totally reasonable!
* If the CDN caches the requests, then the customer is now vulnerable to a
new cache-analysis vulnerability.
* If the CDN doesn't cache the requests, then the customer is now
vulnerable to a new DOS vulnerability, in that the origin can be tipped
over or locked out via the throttling.

In this setup I say middle-box because the CDN is proxying requests. The
latter problem here is created for the origin; but by the CDN. It's a real
awful externality; because the CDN has a lot of incentive not to invest in
real replay protection and hand-wave the issue away. That's my real core
interoperability concern.

> I agree with this.  Which is why I prefer separate streams for early data,
> and some kind of signaling to the content provider that is clear and
> unambiguous.  I don't know how to do that when, say, the intermediary/CDN
> has a persistent connection to the backend...
>

That doesn't seem to be what some have deployed in the experimental
deployments. There seems to be remarkably little traction for the separate
streams.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 12 Jun 2017 11:59:05 -0700

> has a persistent connection to the backend...

I've given this some thought, and I think it might be unworkable to have
some kind of end-to-end 0-RTT. A simple example is that a CDN might want to
make a slightly different request, with extra headers, towards the origin
than the request that came in from the browser. For instance, the CDN might
add an If-None-Match: or an If-Modified-Since. But those may not fit within
the 0-RTT size limit.

It gets really complicated across layering boundaries to have the CDN only
accept 0-RTT if the origin also does, and if the request towards the origin
will also fit, and so on. I think the CDN would have to defer accepting the
0-RTT from the browser until the origin accepted the 0-RTT from the origin;
which defeats a lot of the intended speed/throughput benefit.

Through this I've come to the conclusion that separate streams create more
problems than they solve, and robust replay mitigation is a better answer.

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Jun 2017 14:32:32 +0300

> - Describe the attacks that Colm described.

That was mainly five attacks, right?

- 0-RTT without stateful anti-replay allows for very high number of
  replays, breaking rate limiting systems, even high-performance
  ones, resulting in an opening for DDoS attacks.
- 0-RTT without stateful anti-replay allows for very high number of
  replays, allowing exploiting timing side channels for information
  leakage. Very few if any applications are engineered to mitigate
  or eliminate such side channels.
- 0-RTT without global anti-replay allows leaking informtation
  from the 0-RTT data via cache timing attacks. HTTP GET URLs
  sent to CDNs are especially vulernable.
- 0-RTT without global anti-replay allows non-idempotent actions
  contained in 0-RTT data to be repeated potentially lots of times.
  Abuse of HTTP GET for non-idempotent actions is fairly common.
- 0-RTT allows easily reordering request with retransmission from
  the client. This can lead to various unexpected application
  behavior if possibilty of such reordering is not taken into account.
  "Eventially consistent" datastores are especially vulernable.

>   retransmission) are superior.

I don't remember seeing any scheme that looks feasible to implement,
and that could limit amount replays but not to one per "server".

(Of course, definition of "server" might sometimes be tricky, e.g.
8 "servers" all running in the same virtual machine.

Also, I think SHOULD is bit questionable when not following it
is almost certain to lead to severe problems.

>   pointed out, it's a nice pre-filter for either of these other

Basically, the strike register is unimplementatble without bounding
the replay window first in time.

But I don't think that should be represented as a stateless
mechanism, merely as a way of limiting the resources used by
the strike register.

>   requests in 0-RTT, but allow implementations to determine what is
 
Also:

- Note that 0-RTT exporters are not safe for authentication unless
  the server does global anti-replay on 0-RTT.

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Tue, 13 Jun 2017 12:06:26 -0700

>   the server does global anti-replay on 0-RTT.

I do not think this is the case.  Nick Harper has proposed an RFC for token
binding over 0-RTT:

    https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-02

In the same way servers can ensure tickets are single-use (by binding them
to a server/metro/orbit and having local ticket caches), we can ensure that
each retransmission carries a unique auth signature.  I would state the
situation like this:

  - Note that 0-RTT exporters are not safe for authentication on servers
that do not enforce single-use tickets, or for clients that do not
recompute authentication signatures on retransmission of early data.

Even this is only partially true.  Anti-replay can be built above the TLS
layer.  I'm considering doing token-binding replay defense in the
authentication backend, to help ensure the token-binding guarantee: that
auth tokens taken from one device cannot be used from another device
without continued access to the first device's signing oracle.
Unfortunately, 0-RTT master resumption secrets are a new kind of auth
bearer token, and the token binding spec does not cover them.

Bill

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 13 Jun 2017 16:24:12 -0400

> review it for conformance to these principles, not to re-litigate
Thank you for taking time to summarize this!

All of those seem good to me.  I am not sure "retransmission" is a good
term here, since it can be easily confused with the TCP/QUIC-level
retransmissions.

  -- Victor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Jun 2017 23:51:13 +0300

> recompute authentication signatures on retransmission of early data.

"Single-use tickets" imply global anti-replay.

And the latter part is way too obscure. I have no idea how it is
trying to fix ClientHello replay resulting the same exporter
output.

E.g., for Triple Handshake, one can mitigate the vulernability for
using the exporter outputs for authentication, but the EMS spec does
not document the methods of doing this for good reasons.

> bearer token, and the token binding spec does not cover them.

Doing stuff like this gets more and more complicated and fragile as
one moves up the layer stack.

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Tue, 13 Jun 2017 15:24:24 -0700

> "Single-use tickets" imply global anti-replay.

I assumed "gobal anti-replay" meant there would be a globally synchronized
cache of valid single-use tickets.  It sounds like you mean "global
anti-replay" includes schemes using orbit/metro/server bound tickets, since
they can support single-use tickets.  In that case, I agree with you, but I
think the phrase "single-use tickets" may be less confusing.  Maybe just
say "anti-replay" instead of "global anti-replay"?

> trying to fix ClientHello replay resulting the same exporter

I don't know what you mean by "resulting the same exporter output."  Auth
signatures in a 1-RTT fallback need to be recomputed using the 1-RTT
exporter to avoid having the same signature accepted twice.  Maybe this is
too specific and should be left out.

> one moves up the layer stack.

It depends on the task.  Moving channel ID from the TLS layer to token
binding in the HTTP layer should simplify the TLS state machine enough to
justify the change.  Anti-replay in the TLS layer would be good for 0-RTT
token binding, but the cost and complexity of running the whole user-facing
fleet of servers with anti-replay caches is huge, many times higher than
the cost of token-binding anti-replay in the backend.  Also, the
authentication backend is where bound tokens are currently verified, so
putting the anti-replay there seems like the appropriate layer.

I'm still not sure this scheme is worth implementing, but without it, I do
not think we can support client certificates or token binding over 0-RTT.
It doesn't really matter for the TLS 1.3 spec.  I'm just pointing out that
the statement "0-RTT auth is insecure without anti-replay defense" is not
100% accurate.  There are other ways to improve the security.

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 14 Jun 2017 20:45:31 +0300

> say "anti-replay" instead of "global anti-replay"?

IMO, "anti-replay" also includes per-server anti-replay, which archives
"at most N replays" in global scale.

Of course, the ticket scope of server can be wider than the 0-RTT scope
(the server accepts tickets but rejects 0-RTT from any ticket in
between).
 
> too specific and should be left out.

If you replay ClientHello and it gets accepted twice, including to
different servers, both connections have the same 0-RTT exporter values.

The 1-RTT exporter values will not be the same, but this is not helpful
for 0-RTT data, or for that matter any 1-RTT data unless exporters are
switched mid-stream.

> justify the change.

Implementing such thing without some TLS support at application layer is
just crazy.

IMO, the only reason token binding concerns itself at all with TLS is
that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when
token binding was started. Those (together with exporters) would have
enabled token binding in HTTPS without having to mess with TLS.

(The messing with TLS in token binding seems to be solely about saving
round-trips!)

> Anti-replay in the TLS layer would be good for 0-RTT

That greatly depends on the implementation and deployment. That's why it
is more fragile.

E.g. run more than one authentication backend for 0-RTT scope, and
your application layer anti-replay breaks. And I'm not convinced the
scale of anti-replay cache would be much smaller at application layer, in
fact, it could be even biger.

> 100% accurate.  There are other ways to improve the security.

Well, client certificates are currently forbidden for connections with
0-RTT data (indirectly, but it is still forbidden). It could become possible
in the future.

-Ilari

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 23 Jun 2017 09:21:42 -0700

Hi Ekr,

Discussion on this topic is dying down, can you post a PR so we can see the
proposed text.  There is still some discussion on the API thread so there
may be some additional modifications coming in that area.

On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara <[email-masked]>
wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Jun 2017 10:44:00 -0700

PR up:
https://github.com/tlswg/tls13-spec/pull/1034

On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <[email-masked]> wrote:

> Hi Ekr,
>
> Discussion on this topic is dying down, can you post a PR so we can see
> the proposed text.  There is still some discussion on the API thread so
> there may be some additional modifications coming in that area.
>
>
> On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara <
> [email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 24 Jun 2017 08:27:27 +0300

> https://github.com/tlswg/tls13-spec/pull/1034

I didn't see any mention of the cache probing attack.

I.e., Leak data from 0-RTT requests (especially URLs) by first priming
caches using 0-RTT replay and then probe the caches using normal
requests.

This attack can be viable even at low replay count, it isn't like the
others that require very high number of replays. And in fact, it
benefits from having numerious zones.

E.g., CDNs that have multiple datacenters that accept 0-RTT tickets of
each other seem vulernable to abusing this for discovering HTTP GET
URLs in 0-RTT requests.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Jun 2017 07:05:11 -0700

i mentioned it here, but perhaps it's not clear enough.

"If data can be replayed a large number of times, additional attacks
become possible. Specifically, attackers can use multiple replays to
exploit information leakage via side channels such as timing network
caches or measuring the speed of cryptographic operations."

I've got some other comments to resolve Monday I'll try to get to this then,
but I'd also welcome suggested text on the PR.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 26 Jun 2017 09:43:20 +0300

> but I'd also welcome suggested text on the PR.

I understood that the cache probing attack requires much less replays
than the other side-channel ones. And furthermore, distributing the
replays among zones makes the attack easier (because replay with the
cached data hot doesn't tell that much).

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 26 Jun 2017 10:25:46 -0700

> cached data hot doesn't tell that much).

In practice with real world HTTP caches, one replay is often sufficient.
That's because in addition to the faster load time you can look at the
cache headers (like max-age) to pinpoint that it was the replay that put
the item in the cache. This would work with DNS too, where TTL or RRSET
cycling leaks more information in the same way.

Using more zones does help, and if the attacker were targeting a busy
cache, then it can certainly help to weed out the noise and increase the
likelihood of finding a zone/node where the cache is empty to begin with.

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Jun 2017 11:16:02 -0700

OK, I'll move this out of the "if you can do a lot of replays" section

On Mon, Jun 26, 2017 at 10:25 AM, Colm MacCárthaigh <[email-masked]>
wrote:

>
>
> On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara <

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Jun 2017 08:15:38 +1000

> On 27 Jun 2017, at 3:25 am, Colm MacCárthaigh <[email-masked]> wrote:
> 
> 
> 
> On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara <[email-masked]> wrote:
> In practice with real world HTTP caches, one replay is often sufficient. That's because in addition to the faster load time you can look at the cache headers (like max-age)

I think you mean Age. 

> to pinpoint that it was the replay that put the item in the cache. This would work with DNS too, where TTL or RRSET cycling leaks more information in the same way.  
> 
> Using more zones does help, and if the attacker were targeting a busy cache, then it can certainly help to weed out the noise and increase the likelihood of finding a zone/node where the cache is empty to begin with. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 27 Jun 2017 21:49:07 +0300

> OK, I'll move this out of the "if you can do a lot of replays" section

Another thing:

The PR briefly mentions to be careful with 0-RTT exporters, but nothing
concrete-looking.

If 0-RTT data is replayed and the replay accepted, all replays share the
same 0-RTT exporter values.  This causes two kinds of problems:

1) If 0-RTT exporters are used for authentication, then an attacker
in possession of resumption secret and DHE key (if any) can replay the
generated tokens to another connection with replayed 0-RTT, even
without the better-protected authentication key.

2) If 0-RTT exporters are used for key material for to-client
direction, then the replays will have the same keying material, which
is highly dangerous with many encryption algorithms.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jun 2017 13:51:19 -0700

> without the better-protected authentication key.

I think this mostly belongs with the token binding spec, but I added a
little
bit here.

> is highly dangerous with many encryption algorithms.

Right. One should not do this. I added text.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jun 2017 13:53:32 -0700

I have updated the PR to match people's comments. I would like to merge
this soon, so please get any final comments in.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Jun 2017 11:32:51 -0500

On 06/29/2017 03:53 PM, Eric Rescorla wrote:
> I have updated the PR to match people's comments. I would like to
> merge this soon, so please get any final comments in.

I made a couple comments on the PR that are more appropriate for the
list, so I'll repeat them here and hopefully get replies from the
broader audience.

First off, I think we should MUST-level require servers to implement a
hard limit on the number of replays accepted.  However, it doesn't quite
seem realistic to require "MUST use either [single-use tickets] or
[ClientHello recording]".  My preference would be "MUST use either
[single-use tickets], [ClientHello recording], or equivalently strong
protection", but I don't know what level of support we have for such a
strong requirement.  As an alternative, I will also put out "MUST limit
replays to at most the number of endpoints capable of accepting
connections for a given identity, and SHOULD provide even stronger
replay protections, such as [single-use tickets] or [ClientHello
recording]."  I think we have general agreement that strong anti-replay
as described in the document is feasible for a single-server deployment,
and this last formulation is achievable in multi-server environments by
just giving each server its own local per-server protection.  (My main
reason for wanting a MUST-level hard cap is that I worry that
millions/billions of replays will have really nasty consequences in
terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple
forums/email subjects, so I've also probably forgotten some of the
arguments presented against having MUST-level strong anti-replay
requirements; I'd greatly appreciate if someone could repeat them here
for everyone's consideration.

The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" alert
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for
+as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and
accepting the PSK but rejecting 0-RTT (if a matching ClientHello is
found), especially not without giving guidance as to why they might
choose one or the other.  My natural inclination would be to have the
expected behavior be to abort and only fall back to the other behavior
if using a scheme with false positives, but Ekr thinks Erik Nygren was
in support of just continuing on with 1-RTT.  It looks like this was
https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 ,
where I ... took the opposite position from what I just said my "natural
inclination" was, amusingly enough.  But still, why does this need to be
a choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it
would be reasonable in all the cases mentioned so far.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jun 2017 09:53:29 -0700

On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <[email-masked]> wrote:

> I made a couple comments on the PR that are more appropriate for the list,
> so I'll repeat them here and hopefully get replies from the broader
> audience.
>
>
> replays to at most the number of endpoints capable of accepting connections
> for a given identity, and SHOULD provide even stronger replay protections,
> such as [single-use tickets] or [ClientHello recording]."  I think we have
> general agreement that strong anti-replay as described in the document is
> feasible for a single-server deployment, and this last formulation is
> achievable in multi-server environments by just giving each server its own
> local per-server protection.  (My main reason for wanting a MUST-level hard
> cap is that I worry that millions/billions of replays will have really
> nasty consequences in terms of DoS and side channel issues.)
>
> requirements; I'd greatly appreciate if someone could repeat them here for
> everyone's consideration.
>
>
> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found),
> especially not without giving guidance as to why they might choose one or
> the other.  My natural inclination would be to have the expected behavior
> be to abort and only fall back to the other behavior if using a scheme with
> false positives, but Ekr thinks Erik Nygren was in support of just
> continuing on with 1-RTT.  It looks like this was
> inclination" was, amusingly enough.  But still, why does this need to be a
> choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be
> reasonable in all the cases mentioned so far.
>

Well, my reason for not wanting to do that is that it's a clear replay and
so should
be a hard failure. So, I'd be happy to mandate abort the handshake, but if
we can't
agree on that, I'd rather have a choice.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Jun 2017 11:59:59 -0500

On 06/30/2017 11:53 AM, Eric Rescorla wrote:
>
> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     I am not sure why we are giving servers a choice between aborting
>     and accepting the PSK but rejecting 0-RTT (if a matching
>     ClientHello is found), especially not without giving guidance as
>     to why they might choose one or the other.  My natural inclination
>     would be to have the expected behavior be to abort and only fall
>     back to the other behavior if using a scheme with false positives,
>     but Ekr thinks Erik Nygren was in support of just continuing on
>     with 1-RTT.  It looks like this was
>     https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_1005-23discussion-5Fr114924733&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=qIhheftV5IdrTjjQ2fnsyL7mpbxBb7pw2MXevyQDsAs&s=zakCTxTGwP_fbyNl2IETAkdWTkuorAi0cTV9ap91MRM&e=>
>     , where I ... took the opposite position from what I just said my
>     "natural inclination" was, amusingly enough.  But still, why does
>     this need to be a choice?  Rejecting 0-RTT and continuing on to
>     1-RTT seems like it would be reasonable in all the cases mentioned
>     so far.
>
>
> Well, my reason for not wanting to do that is that it's a clear replay
> and so should
> be a hard failure. So, I'd be happy to mandate abort the handshake,
> but if we can't

Would you be willing to add some discussion about how aborting might
give an information channel to an attacker maliciously replaying packets
even though it is clearly an error that should be rejected (eventually)?

-Ben

---

From: Erik Nygren <[email-masked]>
Date: Fri, 30 Jun 2017 13:19:05 -0400

On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <[email-masked]> wrote:

>> list, so I'll repeat them here and hopefully get replies from the broader
>> audience.
>>
>>

Are there scenarios where the duplication might be accidental rather than a
malicious attack?
For example, one might see cases where combining 0RTT with TFO and network
packet
duplication could result in two initial 0RTT flights.  One could also see
"TCP accelerator"
middleboxes doing similar things where the first flight gets replayed.

In both of these cases, only one will actually successfully establish a TLS
connection
and move forwards, but if the successful one is the one that is aborted
then
the connection will fail.  If 0RTT is rejected and both are allowed to
proceed,
then the bogus accidental replay will be dropped and the legit connection
will succeed.

        Erik

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jun 2017 10:23:18 -0700

On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren <[email-masked]> wrote:

>> be a hard failure. So, I'd be happy to mandate abort the handshake, but
>> if we can't
> Are there scenarios where the duplication might be accidental rather than
> a malicious attack?
>
> middleboxes doing similar things where the first flight gets replayed.

Sure, and this is a good reason to hard fail because it helps us find stuff
like that.

> the connection will fail.
>

Sure, though of course clients can also retry.

-Ekr

>   If 0RTT is rejected and both are allowed to proceed,