Re: [quicwg/base-drafts] Discard Initial keys as soon as possible (#2045)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -3592,6 +3594,21 @@ and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
 frame sent in the first Initial packet.  Cryptographic handshake messages
 subsequent to the first do not need to fit within a single UDP datagram.
 
+
+### Abandoning Initial Packets {#discard-initial}
+
+A client stops both sending and accepting Initial packets when it sends its
+first Handshake packet.  A server stops sending and accepting Initial packets
+when it receives its first Handshake packet.  Though packets might still be in
+flight or awaiting acknowledgment, no further Initial packets need to be
+exchanged beyond this point.  Initial packet protection keys are discarded (see
+Section 4.10 of {{QUIC-TLS}}) along with any loss recovery and congestion
+control state (see Sections 5.3.1.2 and 6.9 of {{QUIC-RECOVERY}}).

Okay, I see that reading of the -recovery text.  But that's really weird -- we *do* know that these packets have arrived, so why define a special operation for "forgetting" packets rather than just marking them arrived as normal and be done?

If one component were trying to game the other -- for example, by sending many Initial packets with redundant data -- then you wouldn't want to let the packetizer force many packets to be "acknowledged" when only one actually needed to get through to produce the effect.  But the ways to game that I see offhand are intra-implementation, and I think we can say that's not an attack of concern.

-- 
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/pull/2045#discussion_r237569491