Re: [TLS] Closing on 0-RTT

[Benjamin Kaduk <[e-mail]>]

On 06/30/2017 11:53 AM, Eric Rescorla wrote:
>
> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     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
>     <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
> agree on that, I'd rather have a choice.
>

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