From 5b13263df6ea882fe5f1d88a22d4570beca9434b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 9 Jun 2020 12:24:26 +1000 Subject: [PATCH] Move recommendation from the note into mainline Closes #3729. --- draft-ietf-quic-transport.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 35c5ac407b..77a8e9ee3a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1975,8 +1975,9 @@ When a server receives an Initial packet with an address validation token, it MUST attempt to validate the token, unless it has already completed address validation. If the token is invalid then the server SHOULD proceed as if the client did not have a validated address, including potentially sending -a Retry. If the validation succeeds, the server SHOULD then allow the -handshake to proceed. +a Retry. A server SHOULD encode tokens provided with NEW_TOKEN frames and Retry +packets differently, and validate the latter more strictly. If the validation +succeeds, the server SHOULD then allow the handshake to proceed. Note: @@ -1984,9 +1985,7 @@ Note: the packet is that the client might have received the token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if - the packet is discarded. A server SHOULD encode tokens provided with - NEW_TOKEN frames and Retry packets differently, and validate the latter more - strictly. + the packet is discarded. 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