Re: [TLS] Closing on 0-RTT

[Benjamin Kaduk <[e-mail]>]

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