Subject: [quicwg/base-drafts] 1-RTT stateless rejects (#655)

From: Victor Vasiliev <[email-masked]>
Date: Thu, 22 Jun 2017 16:00:48 -0700

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
1. Server sends ServerHello, Certificate, CertificateVerify, Finished, NST and close_verify.
1. Client sends ClientHello with the ticket it just received, plus any 0-RTT-eligible data it wants.
1. 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 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/655

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Jun 2017 17:47:13 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/655#issuecomment-310540175

---

From: ianswett <[email-masked]>
Date: Mon, 26 Jun 2017 12:27:15 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/655#issuecomment-311157678

---

From: ianswett <[email-masked]>
Date: Mon, 26 Jun 2017 12:29:22 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/655#issuecomment-311158159