Re: [quicwg/base-drafts] Handshake deadlock (#1824)

[martinduke <[e-mail]>]

martinduke commented on this pull request.

If it's too late and you're cool with the changes, I can drop a PR.

> @@ -875,11 +875,18 @@ The first Handshake packet sent by a server contains a packet number of 0.
 Handshake packets are their own packet number space.  Packet numbers are
 incremented normally for other Handshake packets.
 
-Servers MUST NOT send more than three datagrams including Initial and Handshake
-packets without receiving a packet from a verified source address.  Source
-addresses can be verified through an address validation token
-(delivered via a Retry packet or a NEW_TOKEN frame) or by receiving
-any message from the client encrypted using the Handshake keys.
+Servers MUST NOT send more than three times as many bytes as the number of bytes
+received prior to verifying the client's address.  Source addresses can be
+verified through an address validation token (delivered via a Retry packet or
+a NEW_TOKEN frame) or by receiving any message from the client encrypted using
+the Handshake keys.  This limit exists to mitigate amplification attacks.
+
+In order to prevent this limit causing a handshake deadlock, the client SHOULD
+send a packet as large as the Initial containing only PADDING if it has no
+other data to send and does not yet have the Handshake keys.  If the client
+has no data to send and the Hanshake keys are available, it SHOULD send a

... send a Handshake packet ...

> -packets without receiving a packet from a verified source address.  Source
-addresses can be verified through an address validation token
-(delivered via a Retry packet or a NEW_TOKEN frame) or by receiving
-any message from the client encrypted using the Handshake keys.
+Servers MUST NOT send more than three times as many bytes as the number of bytes
+received prior to verifying the client's address.  Source addresses can be
+verified through an address validation token (delivered via a Retry packet or
+a NEW_TOKEN frame) or by receiving any message from the client encrypted using
+the Handshake keys.  This limit exists to mitigate amplification attacks.
+
+In order to prevent this limit causing a handshake deadlock, the client SHOULD
+send a packet as large as the Initial containing only PADDING if it has no
+other data to send and does not yet have the Handshake keys.  If the client
+has no data to send and the Hanshake keys are available, it SHOULD send a
+packet with a single byte of padding.  Details on when to send these PADDING
+packets are in {{QUIC-RECOVERY}}.

I couldn't find these details after a quick skim.

> @@ -875,11 +875,18 @@ The first Handshake packet sent by a server contains a packet number of 0.
 Handshake packets are their own packet number space.  Packet numbers are
 incremented normally for other Handshake packets.
 
-Servers MUST NOT send more than three datagrams including Initial and Handshake
-packets without receiving a packet from a verified source address.  Source
-addresses can be verified through an address validation token
-(delivered via a Retry packet or a NEW_TOKEN frame) or by receiving
-any message from the client encrypted using the Handshake keys.
+Servers MUST NOT send more than three times as many bytes as the number of bytes
+received prior to verifying the client's address.  Source addresses can be
+verified through an address validation token (delivered via a Retry packet or
+a NEW_TOKEN frame) or by receiving any message from the client encrypted using

I think valid resumption keys should also be sufficient.

> @@ -875,11 +875,18 @@ The first Handshake packet sent by a server contains a packet number of 0.
 Handshake packets are their own packet number space.  Packet numbers are
 incremented normally for other Handshake packets.
 
-Servers MUST NOT send more than three datagrams including Initial and Handshake
-packets without receiving a packet from a verified source address.  Source
-addresses can be verified through an address validation token
-(delivered via a Retry packet or a NEW_TOKEN frame) or by receiving
-any message from the client encrypted using the Handshake keys.
+Servers MUST NOT send more than three times as many bytes as the number of bytes
+received prior to verifying the client's address.  Source addresses can be
+verified through an address validation token (delivered via a Retry packet or
+a NEW_TOKEN frame) or by receiving any message from the client encrypted using
+the Handshake keys.  This limit exists to mitigate amplification attacks.
+
+In order to prevent this limit causing a handshake deadlock, the client SHOULD

Is SHOULD sufficient? I feel like this a MUST, or compliant implementations will never complete under certain otherwise recoverable loss scenarios. Perhaps the recovery draft is more strict?

> @@ -875,11 +875,18 @@ The first Handshake packet sent by a server contains a packet number of 0.
 Handshake packets are their own packet number space.  Packet numbers are
 incremented normally for other Handshake packets.
 
-Servers MUST NOT send more than three datagrams including Initial and Handshake
-packets without receiving a packet from a verified source address.  Source
-addresses can be verified through an address validation token
-(delivered via a Retry packet or a NEW_TOKEN frame) or by receiving
-any message from the client encrypted using the Handshake keys.
+Servers MUST NOT send more than three times as many bytes as the number of bytes

I suggest a rephrase: 

Prior to verifying the client's address, servers MUST NOT send more than three times as many bytes as the number of bytes received.

> @@ -875,11 +875,18 @@ The first Handshake packet sent by a server contains a packet number of 0.
 Handshake packets are their own packet number space.  Packet numbers are
 incremented normally for other Handshake packets.
 
-Servers MUST NOT send more than three datagrams including Initial and Handshake
-packets without receiving a packet from a verified source address.  Source
-addresses can be verified through an address validation token
-(delivered via a Retry packet or a NEW_TOKEN frame) or by receiving
-any message from the client encrypted using the Handshake keys.
+Servers MUST NOT send more than three times as many bytes as the number of bytes
+received prior to verifying the client's address.  Source addresses can be
+verified through an address validation token (delivered via a Retry packet or
+a NEW_TOKEN frame) or by processing any message from the client encrypted using

Why not valid resumption keys?

-- 
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/1824#pullrequestreview-161327536