>
> On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> > 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.
> >
>
> 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.
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)
> > 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.
> >
>
> 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.
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.
>
> 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.
>
> 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).
> >
>
> Yep! Agreed :)
Moving the text above to here:
> 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?
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
