Re: HTTP profile for TLS 1.3 0-RTT early data?

On Thu, May 11, 2017 at 07:33:15AM +0200, Willy Tarreau wrote:
> Hi Mark,
> 
> On Thu, May 11, 2017 at 10:23:12AM +1000, Mark Nottingham wrote:
> > If an origin doesn't have robust retry/replay protection in place for
> > non-idempotent requests, it seems operationally simpler and safer for them to
> > disable 0RT, rather than refusing it on a request-by-request basis. That's
> > the discussion I think we should have here...
> 
> That's exactly the situation I'm facing for now with haproxy. A few
> users have asked us to support 0RTT and by lack of way to 1) decide
> which requests are really safe, and 2) tell the client it must replay
> them using 1RTT, for now I refused to enable it. The load balancer
> and the origin server will have a different view of the acceptability
> of 0RTT, and all the chain must be able to accept or reject them, and
> let the client retry.
> 
> I tend to think that a 4xx status code would make sense and would be
> useful to pass the verdict back to the client. For example we could
> return "418 not idempotent".

Reading the cryptographer's concerns regarding 0-RTT, the main ones
seem to be:

- Possible lack of strong anti-replay. Possibly leading to >10^6 (!!!)
  replays. 
  * This is enough to exploit pretty subtle side-channel attacks. And
    these attacks are at least extremely difficult to defend against.
  * This causes severe problems for high-performance rate-limiting
    systems.
- Even one replay messing up "try, wait, readback, retry" clients.
  * These clients try to write an entry, if it fails, wait, try to
    read the entry, and if not there, retry.
- Unordered replay: The server gets the 0-RTT request client deemed
  "failed" after the client's retry.
  * The retry is likely 1-RTT!
- Replaying requests to different cache nodes in order to leak
  information about what was requested
  * Prime cache using replayed requests.
  * Probe cache using known requests.



-Ilari

Received on Thursday, 11 May 2017 17:16:18 UTC