Re: [quicwg/base-drafts] Desirable behavior when it takes time to derive the traffic keys for the next PN space (#3821)

[ianswett <[e-mail]>]

Thanks for filing this.  I think I mostly understand the issue, and I think this is mostly a correctness issue with Chrome.  That being said, we may want to add some caution that this is a potential issue and to avoid handshake operations(ie: cert verification on the client and remote handshaking on the server) from excessively delaying acknowledgements.

I've seen lots of cases when the cert is spread over 3 packets and Chrome ACKs the first two packets before the cert is verified, so this doesn't seem to be a case of key availability.  Google servers don't have cert compression enabled yet, so many certs don't fit into 1 or 2 packets.

The recovery draft already says that peers don't arm for ApplicationData(including 0.5RTT) before the handshake is confirmed.  Knowing the peer has the information to derive the keys isn't really enough, since you'd also have to know the peer has received a packet of the next encryption level.  As a result, I can't think of any changes to this part of the PTO logic I'd want to make.

-- 
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/3821#issuecomment-658277641