From 6ee3df8514b129a2aa5368939b22a09d0090a98f Mon Sep 17 00:00:00 2001 From: martinduke Date: Fri, 19 Oct 2018 15:44:37 -0700 Subject: [PATCH 1/3] Minor edits to amplification attack text I had a late review to PR #1824 because @ianswett had to get it into draft-15, and he encouraged me to file a PR. I believe he has no problem with at least one of these. --- draft-ietf-quic-transport.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 145bb7ca53..b0f6ae3ddc 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1194,13 +1194,14 @@ server then needs to validate that the client owns the address that it claims. QUIC therefore performs source address validation during connection establishment. -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 +Prior to verifying the client's address, servers MUST NOT send more than three +times as many bytes as the number of bytes received. 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 -the Handshake keys. This limit exists to mitigate amplification attacks. +a NEW_TOKEN frame), by processing any message from the client encrypted using +the Handshake keys, or by processing a TLS client hello with a valid +pre-shared key. This limit exists to mitigate amplification attacks. -In order to prevent this limit causing a handshake deadlock, the client SHOULD +In order to prevent this limit causing a handshake deadlock, the client MUST 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 a UDP datagram of at least From 34c3ff7d6ac993194a7766aeacb0f768bb07e006 Mon Sep 17 00:00:00 2001 From: martinduke Date: Sat, 20 Oct 2018 21:54:04 -0700 Subject: [PATCH 2/3] Fixed Martin S. issue. --- 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 b0f6ae3ddc..c33a8ca409 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1198,7 +1198,7 @@ Prior to verifying the client's address, servers MUST NOT send more than three times as many bytes as the number of bytes received. Source addresses can be verified through an address validation token (delivered via a Retry packet or a NEW_TOKEN frame), by processing any message from the client encrypted using -the Handshake keys, or by processing a TLS client hello with a valid +the Handshake keys, or by processing a TLS ClientHello with a valid pre-shared key. This limit exists to mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client MUST From ed30d4f1dcc428e7271a91d2655eeb966d7b56e2 Mon Sep 17 00:00:00 2001 From: martinduke Date: Wed, 24 Oct 2018 14:40:15 -0700 Subject: [PATCH 3/3] Addressed Ian's issue The conditions for address verification were repetitive (and in one case wrong). However, I think this section needs a statement about the Token, which I've added. --- draft-ietf-quic-transport.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c33a8ca409..27347f34e6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1189,17 +1189,18 @@ handshake is too large. This is especially important for 0-RTT, where the server might wish to provide application data traffic - such as a response to a request - in response to the data carried in the early data from the client. +A server can also verify the client address if the client's first Initial +Packet contains a valid address validation token, previously delivered to the +client in a RETRY packet or NEW_TOKEN frame. + To send additional data prior to completing the cryptographic handshake, the server then needs to validate that the client owns the address that it claims. QUIC therefore performs source address validation during connection establishment. Prior to verifying the client's address, servers MUST NOT send more than three -times as many bytes as the number of bytes received. Source addresses can be -verified through an address validation token (delivered via a Retry packet or -a NEW_TOKEN frame), by processing any message from the client encrypted using -the Handshake keys, or by processing a TLS ClientHello with a valid -pre-shared key. This limit exists to mitigate amplification attacks. +times as many bytes as the number of bytes received. This limit exists to +mitigate amplification attacks. In order to prevent this limit causing a handshake deadlock, the client MUST always send a packet upon a handshake timeout, as described in