Re: [quicwg/base-drafts] Write down spoofed packet guarantees (#1347)

[janaiyengar <[e-mail]>]

janaiyengar approved this pull request.

nits, but LGTM

> @@ -4035,35 +4035,35 @@ attack from off the network path.  All QUIC packets contain proof that the
 recipient saw a preceding packet from its peer.
 
 The first mechanism used is the source and destination connection IDs, which are
-required to match those set by a peer.  Except for an Initial packet and
-stateless reset, an endpoint only accepts packets that include a destination
+required to match those set by a peer.  Except for an Initial and stateless
+reset packets, an endpoint only accepts packets that include a destination

capitalize stateless reset

> +recipient saw a preceding packet from its peer.
+
+The first mechanism used is the source and destination connection IDs, which are
+required to match those set by a peer.  Except for an Initial and stateless
+reset packets, an endpoint only accepts packets that include a destination
+connection that matches a connection ID the endpoint previously chose.  This is
+the only protection offered for Version Negotiation packets.
+
+The destination connection ID in an Initial packet is selected by a client to be
+unpredictable, which serves an additional purpose.  The packets that carry the
+cryptographic handshake are protected with a key that is derived from this
+connection ID and salt specific to the QUIC version.  This allows endpoints to
+use the same process for authenticating packets that they receive as they use
+after the cryptographic handshake completes.  Packets that cannot be
+authenticated are discarded.  Protecting packets in this fashion provides a
+strong assurance that the sender of the packet saw the Initial packets and

yeah, this should be "packet"

>  
 These protections are not intended to be effective against an attacker that is
-able to receive QUIC packets.  Such an attacker can potentially send packets
-that will be accepted by QUIC clients or servers.  This version of QUIC only
-attempts to detect this sort of attack.  Interference with the handshake is
-detected when the cryptographic handshake fails.  For the most part, this is a
-property that the cryptographic handshake protocol {{QUIC-TLS}} is required to
-provide, though additional validation is required for version negotiation (see
+able to receive QUIC packets prior to the connection being established.  Such an
+attacker can potentially send packets that will be accepted by QUIC clients or

s/QUIC clients or servers/the QUIC endpoints/ ?

>  
 These protections are not intended to be effective against an attacker that is
-able to receive QUIC packets.  Such an attacker can potentially send packets
-that will be accepted by QUIC clients or servers.  This version of QUIC only
-attempts to detect this sort of attack.  Interference with the handshake is
-detected when the cryptographic handshake fails.  For the most part, this is a
-property that the cryptographic handshake protocol {{QUIC-TLS}} is required to
-provide, though additional validation is required for version negotiation (see
+able to receive QUIC packets prior to the connection being established.  Such an
+attacker can potentially send packets that will be accepted by QUIC clients or
+servers.  This version of QUIC attempts to detect this sort of attack, but it
+expects that endpoints will fail to establish a connection rather than
+recovering.  For the most part, the cryptographic handshake protocol

I think this is fine.

-- 
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/1347#pullrequestreview-122740654