1-RTT stateless rejects

[vasilvv]

Currently, if the server is in position where it has to send stateless rejects, the client has to wait two round trips before it can send any data: one to statelessly get a proof of ability to receive, and one to do the TLS handshake (now with the state).

We can do better than that. Instead of sending only a cookie, the server can also send a certificate and a session ticket, neither of which would require storing any state. The way I envision this is something like this:

1. Client sends the ClientHello
2. Server sends ServerHello, Certificate, CertificateVerify, Finished, NST and close_verify.
3. Client sends ClientHello with the ticket it just received, plus any 0-RTT-eligible data it wants.
4. The rest of the handshake proceeds as usual.

In order to not get stuck in an infinite loop, you'd have to opt into that scheme using an extension, and on the second attempt you opt out of it.

cc @martinthomson @seanturner @ekr @ianswett

[martinthomson]

This is a neat trick. The only challenge - and indeed the main one - is that sending all that stuff from the server is highly unlikely to fit in one packet. That is even if we decide that we can glue a plaintext packet to a protected packet. That means dealing with packet loss somehow, or accepting the possibility that you will have to send this chunk more often.

[ianswett]

Multi-packet rejects are unfortunate, but as long as the cert isn't huge, it should still fit into a few packets, which keeps the amplification factor to a small number like 2 or 3.

The client already has a crypto timer, so I was thinking the server would produce a full reject(Victor's #2) for each full sized CHLO it saw and otherwise store no state in this mode. The spurious retransmit rate of handshake packets is already fairly high because of their dependence on timers based on sometimes poor RTT estimates, so I don't think this would make things much worse.

This was a key motivation for Victor's proposal to do cert compression(now adopted by the TLS WG) BTW.

[ianswett]

To be clear. I think this is an excellent proposal and I'm happy to add any documentation to the recovery doc to clarify this case if necessary.

[martinthomson]

@vasilvv, we don't need any new mechanisms to support this hack. If you want to document how to do this (as well as the limitations), then we would be happy to consider a PR.

[kazuho]

The only challenge - and indeed the main one - is that sending all that stuff from the server is highly unlikely to fit in one packet.

I would like to point out that the server has no information to choose the correct certificate.

[martinthomson]

Tokyo conclusion: @vasilvv is surprised this is still open and thought this was v2. Now it is.