On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla <e...@rtfm.com> 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.
>
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.
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 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
> On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh <c...@allcosts.net>
> 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://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
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
