Re: [TLS] 0-RTT and Anti-Replay

[Andrey Jivsov <[e-mail]>]

On 03/22/2015 08:35 PM, Martin Thomson wrote:
> On 22 March 2015 at 20:19, Eric Rescorla <[e-mail]> wrote:
>>> One way to solve this is to say that the server must *fail* 0-RTT, as
>>> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is
>>> not that of this server.
>>
>> Yeah, this is what I claimed is "implausible" in my original message.
>>
>> My concern here is that this basically means that implementations get
>> punished with random failures for any data center/routing instabilities...
> I don't see any way that we can support a mode that fails with
> increased probability like this.  I think that the only real options
> here are #2 and #3.  I'm tending toward a requirement for marking the
> data as being explicitly replayable, simply because I don't think we
> should leave applications with the awkward choice of deciding between
> resend and something else.  Mainly because I don't know what that
> something else looks like.
>
> For HTTP, I think we can use that first flight for idempotent queries
> quite easily and (at worst) the HTTP/2 connection preface.


I was thinking about in terms of two websites from different companies A 
and B.  They are independent and they get different orbit IDs. If A sees 
an orbit ID of B that A would never have sent, this is a replay. An 
error is appropriate on such mismatch.

Likewise, A, B can be divisions in the same company, in which case, 
again, there are different Orbit IDs and an error on mismatch.

When A and B are load-balanced, e.g. by DNS entries, then A, B are in 
the same orbit. In this case they should use the same DB.

(I probably re-defined the "orbit". In my proposal it's a persistent ID 
that survives the reboot ).

If the data center is misconfigured or a client confused the origin of 
the 0-RTT state, isn't an error appropriate? Otherwise, yes, there would 
need to be restrictions on data sent in 0-RTT.