From af5c4152a46b1a0de3654a31e9f0c5a18d0ab6b3 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 14:21:53 -0400 Subject: [PATCH 1/9] Handshake deadlock Fixes #1764 --- draft-ietf-quic-transport.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0d0bed9bbb..83d64af28d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -875,11 +875,17 @@ 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 +packet with a single byte of padding. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE From 3c2c305fed8900ff0e6d1079a2f24d0461620571 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 14:23:51 -0400 Subject: [PATCH 2/9] Update draft-ietf-quic-transport.md Referenced QUIC-RECOVERY, which I can update once this PR has landed. --- draft-ietf-quic-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 83d64af28d..6f1f0258bc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -885,7 +885,8 @@ 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. +packet with a single byte of padding. Details on when to send these PADDING +packets are in {{QUIC-RECOVERY}}. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE From 6251bcf210325a3b0c3084ee16bf90f55825f30e Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:10:46 -0400 Subject: [PATCH 3/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 6f1f0258bc..d9ddc663e5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -884,7 +884,7 @@ 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 +has no data to send and the Handshake 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}}. From 3ccf31538d9d2bff91d38981cc37f4adad5a8bb6 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:11:16 -0400 Subject: [PATCH 4/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d9ddc663e5..360325e28c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -878,7 +878,7 @@ incremented normally for other Handshake packets. 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 +a NEW_TOKEN frame) or by processing 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 From ea331de08754682d835b2245920f647a81a0be67 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:18:05 -0400 Subject: [PATCH 5/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 360325e28c..c67c51e67c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -882,11 +882,11 @@ a NEW_TOKEN frame) or by processing 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 Handshake 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}}. +always send a packet upon a handshake timeout, as described in +{{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have +Handshake keys, it should send a packet as large as the Initial containing +only PADDING. If the client has Handshake keys, it SHOULD send a packet +containing only PADDING. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE From 165e36dc43f42fb2f3f449e978d08d4a25c77f29 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:24:42 -0400 Subject: [PATCH 6/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c67c51e67c..f2371cedd9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -884,9 +884,9 @@ the Handshake keys. This limit exists to mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client SHOULD always send a packet upon a handshake timeout, as described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have -Handshake keys, it should send a packet as large as the Initial containing -only PADDING. If the client has Handshake keys, it SHOULD send a packet -containing only PADDING. +Handshake keys, it SHOULD send an Initial packet of at least 1200 octets +containing only PADDING. If the client has Handshake keys, it SHOULD send a +Handshake packet containing only PADDING. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE From fba810b6e4d312051501f6d140f1167d002ec930 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:29:42 -0400 Subject: [PATCH 7/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f2371cedd9..45624469df 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -884,9 +884,8 @@ the Handshake keys. This limit exists to mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client SHOULD always send a packet upon a handshake timeout, as described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have -Handshake keys, it SHOULD send an Initial packet of at least 1200 octets -containing only PADDING. If the client has Handshake keys, it SHOULD send a -Handshake packet containing only PADDING. +Handshake keys, it SHOULD send an Initial packet of at least 1200 octets. +If the client has Handshake keys, it SHOULD send a Handshake packet. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE From a3a2299fbbb655cdac342e1ae4e31924f6004113 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 2 Oct 2018 18:31:25 -0400 Subject: [PATCH 8/9] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 45624469df..0f3c04ad9c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -884,8 +884,9 @@ the Handshake keys. This limit exists to mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client SHOULD always send a packet upon a handshake timeout, as described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have -Handshake keys, it SHOULD send an Initial packet of at least 1200 octets. -If the client has Handshake keys, it SHOULD send a Handshake packet. +Handshake keys, it SHOULD send an Initial packet in UDP datagram of at least +1200 octets. If the client has Handshake keys, it SHOULD send a Handshake +packet. The payload of this packet contains CRYPTO frames and could contain PADDING, or ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE From 761fdf7959a29db6de6669bd081e9c3efd4264a9 Mon Sep 17 00:00:00 2001 From: janaiyengar Date: Tue, 2 Oct 2018 18:54:59 -0400 Subject: [PATCH 9/9] nit --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0f3c04ad9c..19a7530e67 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -884,7 +884,7 @@ the Handshake keys. This limit exists to mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client SHOULD always send a packet upon a handshake timeout, as described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have -Handshake keys, it SHOULD send an Initial packet in UDP datagram of at least +Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 octets. If the client has Handshake keys, it SHOULD send a Handshake packet.