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

On Thu, May 11, 2017 at 10:02 AM, Willy Tarreau <w@1wt.eu> wrote:

>
> Another point is that given the problem here is to properly map HTTP
> semantics on top of a potentially unsafe transport, I really think it
> totally makes sense to use HTTP semantics (such as status codes) to
> address it. It also means for example that clients will be able to
> send POST requests (or those more than a few MSS) with Expect:100
> letting the other end decide whether or not to return a 100 or a 4xx,
> so for zero extra cost compared to the 1-RTT we can benefit from some
> optimally safe opportunistic attempts to use 0-RTT most of the time
> in a way where safety can be decided at the same place the action will
> be taken.


I agree we certainly will need an HTTP status code here and require
clients that implement sending 0-RTT early data to understand that status
code
before sending the early data.   (This may be one reason there's urgency to
specify
something soon before clients start implementing without a specification.)

I really like Kazuho's idea for HTTP/2 connections.  There may also be a way
for H2 proxies to translate between that and status codes.  (ie, if they
get the HTTP 4xx
status code from upstream they can make sure that an 1-RTT connection is
established
and verified, possibly sending an H2 PING to do so, before resending the
HTTP request
as "early data verified by 1RTT handshake".)

Note that all of this only works for providing safety against replay
if the decision on when to require 1-RTT is deterministic for a given
request.
For example, doing an H2 PING along with the server_hello and waiting for
its
response before processing the request only helps if this will always happen
for a given early_data request.  The early data can always be replayed so
just
because it gets verified by one full 1-RTT handshake doesn't mean that same
early data can't just get replayed without a 1-RTT handshake by an attacker
immediately afterwards.

       Erik