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

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 1 Jun 2017 10:10:53 +0300

On Wed, May 31, 2017 at 03:49:03PM -0400, Victor Vasiliev wrote:
> 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.
> >
> > If the methods are too inconvenient, the secure alternative is to not use
> > 0-RTT at all.
> >
> > [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.

TLS level "sent data is delivered at most once" is very much possible.
But it requires synchronous state.

And it seems like where "few replays @TLS" would be easier than "no
replays @TLS", is where the replays would be to different servers, with
each server only accepting once. But "few replays" distributed among
different servers is much more dangerous than "few replays" to one
server.

Yes, residual replays will still come through even when TLS guarantees
"at most once" behavior. But turns out one already has to handle that
form of replay, due to wonders of web browser behavior (and reordering
attacks abusing timeouts). It is TLS not guaranteeing "at most once"
behavior (especially across servers) that enables new attacks.

This is fundamentially about what is REQUIRED to do 0-RTT without
nasty security holes. If you think this is too difficult, just don't
do 0-RTT. One extra RTT is a lot better than nasty attacks, with
potential consequences much worse than just some site getting DoSed
or some card chargebacks.

-Ilari

---

From: Victor Vasiliev <[email-masked]>
Date: Thu, 1 Jun 2017 16:50:54 -0400

On Wed, May 31, 2017 at 4:52 PM, Colm MacCárthaigh <[email-masked]>
wrote:
>
> On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev <[email-masked]>
> wrote:
>
>> 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.
>>
>
> 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.
>

I am not sure I agree with this distinction.  I can accept the difference in
terms of how much attacker can retry -- but we've already agreed that
bounding
that number is a good idea.  I don't see any meaningful distinction in other
regards.

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

Sure, but this is just an argument for making N small.  Also, retrys can
also
be directed to arbitrary nodes.

>
>> Your applications already have to
>> contend with replays, it's now just the matter of preventing side-channel
>> amplification.
>>
>
> 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).
>

I am glad we agree on that point.

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

Of course it doesn't protect against the DKG attack, but nothing at that
layer
actually does.

This sounds like an issue with the current wording of the draft.  As I
mentioned, I believe we should be very clear on what the developers should
and
should not expect from TLS.

> So, in other words, since we're now just bargaining about the value of N,
>> 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.
>
>
Sure, but there's a space between "one" and "huge amount".

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

Are you arguing that non-safe requests should be allowed to be sent via
0-RTT?
Because that actually violates reasonable expectations of security
guarantees
for TLS, and I do not believe that is acceptable.

>> I do not believe that this to be the case.  The DKG attack is an attack
>> that allows
>> 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.
>

That's already not acceptable for a lot of applications -- and by enabling
0-RTT for non-safe HTTP requests, we would be pulling the rug from under
them.

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

Sure, but all of those are either:
 (a) side channel attacks covered by guarantee C, or
 (b) a violation of semantic contract between TLS and the application.

> [snip]
>
>
>> 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.
>>
>
> 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.
>

Throttling POST requests is fine -- they shouldn't go over 0-RTT, since they
are not idempotent.  Throttling GET requests in this manner goes at odds
with
RFC 7231:

   Request methods are considered "safe" if their defined semantics are
   essentially read-only; i.e., the client does not request, and does
   not expect, any state change on the origin server as a result of
   applying a safe method to a target resource.  Likewise, reasonable
   use of a safe method is not expected to cause any harm, loss of
   property, or unusual burden on the origin server.

   This definition of safe methods does not prevent an implementation
   from including behavior that is potentially harmful, that is not
   entirely read-only, or that causes side effects while invoking a safe
   method.  What is important, however, is that the client did not
   request that additional behavior and cannot be held accountable for
   it. [...]

Incidentally, guarantee C does solve the throttling problem -- if you get N
replays, you get promise of 1/(N+1) throttled resource available to you.
Deployments which do this with GETs may want to deploy the measures to make
N
very small.  Also, since they already keep track of the state for throttling
purposes, they might add a strike register on top of that.

>
> 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.
>>
>
> I'm all for bounded replay protection, with the bounds being 1 ;-)
>

Why not 2?  What is the difference between 1 and 2?  2 and 3?  3 and 24?
None
of the proposed attacks distinguishes 1 replay and N replays in qualitative
ways (as opposed to giant semantic leap between 0 and 1 replay); only in how
much damage you can do, or how much information you can extract from the
side
channel.

  -- Victor.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 1 Jun 2017 16:59:10 -0700

> that number is a good idea.  I don't see any meaningful distinction in

It's not just a difference in the number of duplicates. With retries, the
client maintains some control, so it can do things like impose delays and
update request IDs. Bill followed up with an exactly relevant example from
Token Binding where the retry intentionally has a different token value.
That kind of control is lost with attacker driven replays.

But even if we focus on just the number; there is something special about
allowing 0 literal replays of a 0-RTT section; it is easy for users to
confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never be
replayable, then I feel like we have a hope of producing a viable 0-RTT
ecosystem. Plenty of providers may screw this up, or try to cut corners,
but if we can ensure that they get failing grades in security testing
tools, or maybe even browser warnings, then we can corral things into a
zone of safety. Otherwise, with no such mechanism, I fear that bad
operators will cause the entire 0-RTT feature to be tainted and entirely
turned off over time by clients.

> be directed to arbitrary nodes.

This is absolutely true, but see my point about the client control.
Regardless, it is a much more difficult attack to carry out. That is to
intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section
and sending it again.

> should not expect from TLS.

Big +1 :)

> Sure, but there's a space between "one" and "huge amount".

It's not just quantitive, it's qualitative too. But now I'm duplicating
myself more than once ;-)

> for TLS, and I do not believe that is acceptable.

I'm just saying that it absolutely will happen, and I don't think any kind
of lawyering about the HTTP spec and REST will change that. Folks use GETs
for non-idempotent side-effect-bearing APIs a lot. And those folks don't
generally understand TLS or have anything to do with it. I see no real
chance of that changing and it's a bit of a deceit for us to think that
it's realistic that there will be these super careful 0-RTT deployments
where everyone from the Webserver administrator to the high-level
application designer is coordinating and fully aware of all of the
implications. It crosses layers that are traditionally quite far apart.

So with that in mind, I argue that we have to make TLS transport as secure
as possible by default, while still delivering 0-RTT because that's such a
beneficial improvement.

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

Yep; but I think /this/ risk is manageable and tolerable. Careful clients,
like the token binding case, can actually mitigate this. I've outlined the
scheme. For careless clients, like browsers, they can mostly ignore this;
since they retry so easily anyway, it's no worse.

But there is *no* proposed mitigation for replayable 0-RTT. So I don't
think that's manageable. Just trying to make a data-driven decision. If
someone presents an alternative mitigation (besides forbidding replays),
I'll change my mind.

> RFC 7231.

Throttling GET requests happens all of the time and is an important
security and fairness measure used by many deployed systems. 0-RTT would
break it. That's not ok.

I don't think it is at odds with RFC 7231 ... which also defines the 503
status code.

> Deployments which do this with GETs may want to deploy the measures to
> make N

One could implement a strike register like that, in the same way as a
coordinated throttling system, they have some things in common. Though it
crosses layers.

> much damage you can do, or how much information you can extract from the

You keep discarding my points about client control and focusing just on the
number; but there quantitative and qualitative differences. That kind of
argument isn't very productive and doesn't move us forward.  But I've
answered above too.

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Jun 2017 17:22:12 -0700

I've just gone through this thread and I'm having a very hard time
understanding what the actual substantive argument is about.

Let me lay out what I think we all agree on.

1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause
   connection failures) then a DKG-style attack where the client
   replays the 0-RTT data in 1-RTT is possible.

2. Because of point #1, applications must implement some form
   of replay-safe semantics.

3. Allowing the attacker to generate an arbitrary number of 0-RTT
   replays without client intervention is dangerous even if
   the application implements replay-safe semantics.

4. If implemented properly, both a single-use ticket and a
   strike-register style mechanism make it possible to limit
   the number of 0-RTT copies which are processed to 1 within
   a given zone (where a zone is defined as having consistent
   storage), so the number of accepted copies of the 0-RTT
   data is N where N is the number of zones.

5. Implementing the level of coherency to get #4 is a pain.

6. If you bind each ticket to a given zone, then you can
   get limit the number of accepted 0-RTT copies to 1
   (for that zone) and accepted 1-RTT copies to 1 (because
   of the DKG attack listed above).

Colm, Victor, do you disagree with this summary?

-Ekr

On Thu, Jun 1, 2017 at 4:59 PM, Colm MacCárthaigh <[email-masked]> wrote:

>> mentioned, I believe we should be very clear on what the developers
>> should and
>>> 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.
>>>
>>>
> You keep discarding my points about client control and focusing just on
> the number; but there quantitative and qualitative differences. That kind
> of argument isn't very productive and doesn't move us forward.  But I've
> answered above too.
>
> --
> Colm
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 1 Jun 2017 23:20:56 -0700

> Let me lay out what I think we all agree on.

This is a good summary, I just have a few clarifications ...

>    replays the 0-RTT data in 1-RTT is possible.

This isn't what I call a replay. It's a second request, but the client is
control of it. That distinction matters because the client can modify it if
it needs to be unique in some way and that turns out to be important for
some cases.

>    of replay-safe semantics.

Yep; though note that in some cases those replay-safe semantics themselves
actually depend on uniquely identifiable requests. For example a protocol
that depends on client-side-versioning, or the token-binding case.

>    the application implements replay-safe semantics.

Yep.

>    data is N where N is the number of zones.

This is much better than the total anarchy of allowing completely unlimited
replay, and it does reduce the risk for side-channels, throttles etc, but I
wouldn't consider it a proper implementation or secure. Importantly it gets
us back to a state where clients may have no control over a deterministic
outcome.

Some clients need idempotency tokens that are consistent for duplicate
requests, this approach works ok then. Other kinds of clients also need
tokens that are unique to each request attempt, this approach doesn't work
ok in that case. That's the qualitative difference.

I'd also add that the suggested optimization here is clearly to support
globally resumable session tickets that are not scoped to a single site.
That's a worthy goal; but it's unfortunate that in the draft design it also
means that 0-RTT sections would be globally scoped. That's seems bad to me
because it's so hostile to forward secrecy, and hostile to protecting the
most critical user-data. What's the point of having FS for everything
except the requests, where the auth details often are, and which can
usually be used to generate the response? Synchronizing keys that can
de-cloak an arbitrary number of such sessions to many data centers spread
out across the world, seems just so defeating. I realize that it's common
today, I've built such systems, but at some point we have to decide that FS
either matters or it doesn't. Are users and their security auditors really
going to live with that? What is the point of rolling out ECDHE so
pervasively only to undo most of the benefit?

Maybe a lot of this dilemma could be avoided if the the PSKs that can be
used for regular resumption and for 0-RTT encryption were separate, with
the latter being scoped smaller and with use-at-most-once semantics.

>    of the DKG attack listed above).

Yep! Agreed :)

-- 
Colm

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 2 Jun 2017 10:57:18 +0300

> the latter being scoped smaller and with use-at-most-once semantics.

The problem here is that the scoping rules can be impossible for the
client to understand (there is possibly anycast involved!)

And also, more serious problem: I thought that server could send
tickets that can't be used for 0-RTT. And this was true a few drafts
back, but now it seems to have gotten lost (at least I can't find
the appropriate requirements). This is a problem, because it forces
any server that implements tickets to deal with at least ignoring
0-RTT (trial decryptions!). Which is complexity that I rather not
have in servers that don't truly implement 0-RTT.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Jun 2017 06:58:59 -0700

It's still there, in 4.6.1.

"The sole extension currently defined for NewSessionTicket is “early_data”,
indicating that the ticket may be used to send 0-RTT data (Section 4.2.9
<https://tlswg.github.io/tls13-spec/#early-data-indication>)). It contains
the following value:"

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Jun 2017 14:25:13 -0700

> it needs to be unique in some way and that turns out to be important for

Sure. For the sake of clarify, I'm going to suggest we call:

- replay == the attacker re-sends the data with no interaction
            with the client
- retransmission == the client re-sends (possibly with some slight
                    changes)

> wouldn't consider it a proper implementation or secure.

I'm not presently taking a position on whether this is secure
or proper, or whatever. I'm just attempting to state the facts
about how the system behaves. From this, I'm going to take
that you agree with this statement.

Moving the text above to here:

> Importantly it gets

This contains a fair bit of advocacy and right now I'm just trying to
get to the point where we agree on the facts. Trying to distill this into
factual statements...

7. With the current design, clients have no way of knowing what, if any,
   anti-replay mechanisms the servers are using. Thus, they cannot be
   sure that servers are ensuring at-most-once semantics for the 0-RTT
   data (at-most-twice if the client retransmits in response to 0-RTT
   failure) [0]. This makes it difficult for clients to know what is
   safe to send in 0-RTT.

8. The more broadly distributed the information required to process
   a session ticket (on the server), the worse the FS situation is,
   with session tickets encrypted under long-lived keys being the
   worst.

I note that you suggest separating out 0-RTT tickets and resumption
tickets, but I don't actually see how that changes matters. As Ilari
notes, it is possible to say that a ticket cannot be used for 0-RTT
and if you have a ticket which can be used for resumption globally
but for 0-RTT at just one site, the server can implement that policy
unilaterally.

In any case, if you think there's some other fact I've failed to
capture here, I'd appreciate it if you'd add it.

Thanks,
-Ekr

[0] Note that scoping resumption down to a given data center does not
help here for removing the DKG attack. Assume that a ticket issued at
data center A is good for both resumption and 0-RTT at A but cannot be
used at all at B. The attacker can still transmit the CH to both A and
B, and have it accepted in 0-RTT at A and a full handshake at B, at
which point the client retransmits.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 2 Jun 2017 17:39:40 -0400

> That kind of control is lost with attacker driven replays.

I am not sure I understand the context in which this is relevant.  I
cannot imagine anyone delay the 1-RTT fallback, given that 0-RTT is
expected to fail regularly.  I also don't understand how changing
request ID would help -- I would assume that for retry safety, you'd
actually want the ID to be the same across all attempts.  Could you give
me a scenario where this actually changes the security properties of the
system?

(I understand the tokbind case -- but tokbind 0-RTT has different
operational requirements from plain TLS; those are documented in
draft-ietf-tokbind-tls13-0rtt and are somewhat out of scope for this
conversation)

> turned off over time by clients.

You can't really audit this property, since you never have a
comprehensive list of endpoints to which a 0-RTT can be replayed.

> intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section

It's within the scope of the threat model.

> as possible by default, while still delivering 0-RTT because that's such a

Well, 0-RTT is inherently unsafe in a sense that it could be retried
at least one time.  This means that we have to draw a line somewhere.
Safe requests seem like a fine line to draw, in a sense that the
ecosystem is already free to try and retry GET requests at will (if you
don't retry yourself, your HTTP proxy might).  If you believe we should
use a more conservative approach, I am happy to hear your suggestions.

> since they retry so easily anyway, it's no worse.

The problem is not just that it's a retry, but it also can be done
out-of-order.

Imagine I have a configuration system, and my client can take out a
global lock for some operation, and normally an update to it looks like
this:

  1. GET to check if the current state needs updating.
  2. POST to take a lock.
  3. GET to check if current state still holds.
  4. POST to update the data held by the lock.
  5. POST to release the lock and publish the notification.
  6. GET to ensure the lock was released.

Now, imagine the following attack:

  a) Between (1) and (2), the attacker resets the TCP connection, after
     the client got the response and the session ticket.
  b) Since the client has the ticket, it 0-RTTs the POST to take out a
     lock.
  c) Attacker redirects the client to another datacenter, which cannot
     accept 0-RTT, so it switches to 1-RTT.
  d) During (b) and (c), the attacker records a transcript of 0-RTT
     request to take out a lock.
  d) The rest of (2)-(6) proceed in normal fashion via client talking to
     the distant datacenter.
  e) Attacker replays the lock being taken out in the datacenter where
     0-RTT would succeed; the lock now is in place, and the client has
     no idea about it.

Because the application layer cannot reasonably assume that such
reordering can happen, it is not acceptable to 0-RTT the POST in #2.

> someone presents an alternative mitigation (besides forbidding replays),

The proposed mitigation is the application-layer profile prohibiting
unsafe requests via 0-RTT.

> I don't think it is at odds with RFC 7231 ... which also defines the 503

As I said, the N may vary and can be set by the service operator
depending on what kind of infrastructure they run.  It might be much
easier for a service to increase its throttling thresholds 10x and set
N=10, than to set N=1.

  -- Victor.

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 2 Jun 2017 17:49:51 -0400

> understanding what the actual substantive argument is about.

I believe at this point we mostly disagree on what specific scenarios
are and are not a concern that should be solved by TLS layer.
Replay/retry distinction might be at core for some disagreements.

>    replays the 0-RTT data in 1-RTT is possible.

Correct.

>    of replay-safe semantics.

Correct.

>    the application implements replay-safe semantics.

Correct, and the specific number is highly situational.

>    data is N where N is the number of zones.

Correct.  Session caches are inherently bound to a single zone.

> 5. Implementing the level of coherency to get #4 is a pain.

Yes.

>    of the DKG attack listed above).
Correct.

  -- Victor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 3 Jun 2017 13:47:19 +0300

> >    replays the 0-RTT data in 1-RTT is possible.

Err, how does not failing connection enable DKG-style attack?

If connection failed on 0-RTT failure, the client would then
presumably just establish a new one (if it can) without 0-RTT,
and we are where we started (the client doesn't even gain
additional knowledge, because 0-RTT ACK exists today).
 
But failing the connection on 0-RTT failure is not nice on
other grounds.

> Correct, and the specific number is highly situational.

For some attacks, it is pretty low (few dozens or less or so),
especially if you can distribute across servers.

> Correct.  Session caches are inherently bound to a single zone.

Which together with "multi-server" attacks imply that 0-RTT tickets
need to be bound to a zone (when doing 0-RTT).

Of course, even only using tickets for 0-RTT in one zone, while
accepting them to skip signatures on others would still leave the
FS problems.

> > 5. Implementing the level of coherency to get #4 is a pain.

Interestingly, the required coherency is quite easy for small sites
(run off VPS or container), it is large sites (multiple datacenters)
that have problems.

-Ilari

---

From: Bill Cox <[email-masked]>
Date: Sun, 4 Jun 2017 12:08:58 -0700

> reordering can happen, it is not acceptable to 0-RTT the POST in #2.

A simpler attack over TLS 1.2 that has the same result:

a) An active attacker waits until she sees what she believes is a lock POST
request.  This can happen at any time during the connection, and the flight
is identified by metadata since it is encrypted.
b) The attacker holds the lock request, and keeps the connection to the
server alive by transmitting a byte to it every minute or so, and
terminates the client connection.
c) The client reconnects, and proceeds with steps 2-6
d) Attacker sends the request to obtain the lock, and now the resource is
locked.

For browsers, this attack seems simpler (no redirect to another data
center), and more powerful (can attack at any point in the stream).  It
obtains the same result (locked resource), and I do not see any simple
mitigation, other than to force clients to make all state changes
transactional.  I realize this attack requires browser retransmition, not
just TLS re-transmission, so it is fundamentally different.  However, isn't
the result the same or worse?

My feeling is that when talking to stateless 0-RTT servers, browsers should
send only idempotent HTTP requests, and accept less-than-perfect FS.  I
also feel they should avoid attempts at client auth over 0-RTT.  However,
when talking to servers that prevent replay (but not re-transmission) I
think browsers should be free to send any HTTP requests over 0-RTT, and
also attempt client auth.  The security properties of 0-RTT data are still
different, but for browsers, where it does not matter whether the
re-transmission is in the browser or TLS layer, the security seems
equivalent to me.

Bill

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 4 Jun 2017 12:36:24 -0700

> - retransmission == the client re-sends (possibly with some slight

O.k., cool.

> but for 0-RTT at just one site, the server can implement that policy

Yep, that's right, and should work.

-- 
Colm

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 4 Jun 2017 15:51:49 -0500

On 06/04/2017 02:08 PM, Bill Cox wrote:
> My feeling is that when talking to stateless 0-RTT servers, browsers
> should send only idempotent HTTP requests, and accept
> less-than-perfect FS.  I also feel they should avoid attempts at
> client auth over 0-RTT.  However, when talking to servers that prevent
> replay (but not re-transmission) I think browsers should be free to
> send any HTTP requests over 0-RTT, and also attempt client auth.  The
> security properties of 0-RTT data are still different, but for
> browsers, where it does not matter whether the re-transmission is in
> the browser or TLS layer, the security seems equivalent to me.

I think we're at a point where multiple people have expressed what their
(subjective) feeling on the desired behavior is, and those feelings are
not in agreement.

So, some more concrete reasoning and deductions seem required in order
for such contributions to be useful towards reaching consensus.

-Ben

P.S. It seems pretty well established that a client will not in general
have a good idea whether it's talking to a server that prevents replay
or is stateless.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 4 Jun 2017 15:57:04 -0500

> Correct.  Session caches are inherently bound to a single zone.

I think we covered this in a couple other messages in a different
subthread, but to be super-clear, 1-RTT session caches can be scoped to
a larger zone than 0-RTT acceptability, at the server's unilateral
discretion.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 4 Jun 2017 18:08:30 -0500

On 06/01/2017 03:50 PM, Victor Vasiliev wrote:
>         meant that it will not be enabled for applications by default,
>         and HTTP clients
>     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. 
>
>
> Are you arguing that non-safe requests should be allowed to be sent
> via 0-RTT?

Do we have a good example of why a non-safe HTTP request in 0-RTT would
lose specific properties required for security?  If so, that seems like
a good thing to include in the TLS 1.3 spec as an example of what can go
wrong.

-Ben

---

From: Bill Cox <[email-masked]>
Date: Sun, 4 Jun 2017 20:06:36 -0700

On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk <[email-masked]> wrote:

> lose specific properties required for security?  If so, that seems like a
> good thing to include in the TLS 1.3 spec as an example of what can go
> wrong.
>
> -Ben
>

I like the example of a POST request saying "send Alice $10".  It is a
request that sophisticated web services will avoid, yet many smaller and
less security savvy sites will continue to support requests like this, so I
think it is worth considering.

Bill

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 Jun 2017 07:17:38 +0300

> On 5 Jun 2017, at 6:06, Bill Cox <[email-masked]> wrote:
> 
> On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Do we have a good example of why a non-safe HTTP request in 0-RTT would lose specific properties required for security?  If so, that seems like a good thing to include in the TLS 1.3 spec as an example of what can go wrong.
> 
> -Ben
> 
> I like the example of a POST request saying "send Alice $10".  It is a request that sophisticated web services will avoid, yet many smaller and less security savvy sites will continue to support requests like this, so I think it is worth considering.
> 

I once saw a router with an HTTPS administration UI that would respond as you’d expect to:

GET mainpage.html?action=rebootDevice

Worse. The router was a firewall and this worked:

GET mainpage.html?action=disablePolicy

Yes.  GET. POST also worked, but for some reason the WebUI generated POSTs.

Of course, it was really secure because the GET was accompanied by a cookie, but I guess the cookie would fit in the early data. Not sure if it would survive a reboot, though.

Yoav