Subject: [quicwg/base-drafts] Set PTO Timer when discarding keys (#3613)

From: martinduke <[email-masked]>
Date: Wed, 29 Apr 2020 18:20:27 -0700

In the recovery draft, the pseudocode does something approximately right (appendix B.9, unfortunately buried in the congestion control example).

There is, however, no text in the spec that says you should set the PTO again when discarding keys if there is still outstanding data in the remaining contexts. This opens up some bizarre corner cases:

Server sends handshake flight + 1RTT
1RTT packets lost
Client acks the handshake flight -- all HS data is acked, and because the HS is not complete we do not set the PTO timer for the 1RTT data.
Client Finished arrives -- no action required by the spec.

It's true that HANDSHAKE_DONE will cover this in the server case, but in the client case where 0RTT is lost, the client might never send a 1RTT ack-eliciting packet. Better for us to tell the server to arm PTO when the handshake is confirmed. Better yet to do it when the handshake is complete, rather than when the keys are discarded (handshake confirmed).

-- 
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/3613

---

From: martinduke <[email-masked]>
Date: Wed, 29 Apr 2020 18:30:22 -0700

I see now that Section 5.2.2 explicitly describes this, so there's no problem here, though I might complain a bit about handshake complete vs. handshake confirmed.

Sorry, feel free to close this issue if you don't think the confirmed thing is worth changing.

-- 
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/3613#issuecomment-621558644

---

From: martinduke <[email-masked]>
Date: Wed, 29 Apr 2020 18:41:22 -0700

I changed the title, since it's wrong.

There might be some useful editorial cleanup here, but the substantive change would be to reset PTO when the handshake is complete, rather than confirmed. The edge case is that the client lost its 0RTT flight and HANDSHAKE_DONE is held up by losses or something. The delay in sending the client's HTTP request could turn out to be quite long.

-- 
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/3613#issuecomment-621561629

---

From: martinduke <[email-masked]>
Date: Wed, 29 Apr 2020 18:51:41 -0700

There's some architectural inconsistency around the treatment of 1RTT PTOs at the end of the handshake.

On the one hand, we are not supposed to set the PTO timer for 1RTT before the handshake is **complete**. This is to prevent us from retransmitting stuff the peer may not be able to process.

On the other hand, we are supposed to arm the PTO timer when the handshake is **confirmed**. This is the point where we're guaranteed that the peer has receive keys.

So there is a weird gap between handshake complete and handshake confirmed where new 1RTT packets will arm the PTO, but outstanding 0RTT or 1RTT packets from before handshake complete will not have an active PTO timer.

This isn't the end of the world -- the connection will recover -- but it doesn't make any sense, and could result in either excessive PTO delays, or 1RTT probes that the peer can't decode.

-- 
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/3613#issuecomment-621564549