From bbef7aab87ea8992e4824e8c45889561ce8b42d3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 27 Aug 2018 15:53:51 +1000 Subject: [PATCH 1/2] Tokens are a mess We can't realistically authenticate all tokens with up to three Retry packets and the NEW_TOKEN message. So they aren't really safe for much. Describe the limitations and advise a very narrow usage. I really hope that this choice doesn't bite us later. It doesn't feel that good, but I don't know how to fix this without going back to just one Retry (and even then a solution would be ugly). Closes #1647. --- draft-ietf-quic-transport.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ae0b3bdc04..cd4e3fc2c7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -786,6 +786,14 @@ Note: the packet is discarded. A server MAY encode tokens provided with NEW_TOKEN frames and Retry packets differently, and validate the latter more strictly. +In a stateless design, a server can use encrypted and authenticated tokens to +pass information to clients that the server can later recover and use to +validate a client address. Tokens are not integrated into the crypto graphic +handshake and so they cannot be authenticated. For instance, a client might be +able to reuse a token. To avoid attacks that exploit this property, a server +can limit its use of tokens to only the information needed validate client +addresses. + ### Starting Packet Numbers From c86245ca9c3483d9228146510bea50a84fefb653 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 28 Aug 2018 10:05:12 +1000 Subject: [PATCH 2/2] unsplit crypto graphic --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cd4e3fc2c7..e75d4b49c3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -788,8 +788,8 @@ Note: In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients that the server can later recover and use to -validate a client address. Tokens are not integrated into the crypto graphic -handshake and so they cannot be authenticated. For instance, a client might be +validate a client address. Tokens are not integrated into the cryptographic +handshake and so they are not authenticated. For instance, a client might be able to reuse a token. To avoid attacks that exploit this property, a server can limit its use of tokens to only the information needed validate client addresses.