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

2017-05-12 17:21 GMT+09:00 Poul-Henning Kamp <phk@phk.freebsd.dk>:
> --------
> In message <CANatvzw9zeVfQMBCXGhakFomL2MaTqFNF65jKWHCDXQQ8rxcTA@mail.gmail.com>
> , Kazuho Oku writes:
>
>>The kind of the deployment I was considering was one that deploys a
>>TLS terminator that just decrypts the data and sends to backend (i.e.
>>TLS to TCP, not an HTTP reverse proxy). My idea was that you could add
>>a new field to the Proxy Protocol that indicates the amount of 0-RTT
>>data that follows the header of the PROXY Protocol.
>
> Can you even know that at the time you send the PROXY protocol header ?

Actually, you do not even need to know or transmit the exact amount of
the 0-RTT data when you transmit the PROXY protocol header. What you
need to transmit is the amount of replayable data.

I believe that there could be several ways, but something like below
should work.

* postpone sending the PROXY Protocol header until receiving the first
flight of 0-RTT data
* include the size of the 0-RTT data being received as an attribute in
the PROXY Protocol header that is sent to the backend
* postpone forwarding the rest of 0-RTT data to the server until the
handshake succeeds

The assumption behind the approach is that the 0-RTT data from the
client (e.g. HTTP request) will likely fit in one packet, possibly in
the same packet that carries ClientHello (or in a few number of
packets that will arrive while the server does DH operation). The
approach also uses the fact that a successful handshake can be used to
rule out the possibility of the 0-RTT data being replayed by an
attacker.

> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.



-- 
Kazuho Oku

Received on Friday, 12 May 2017 11:36:45 UTC