Re: [quicwg/base-drafts] Provide guidelines on token validation (#2132)

MikkelFJ <> Thu, 13 December 2018 08:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0081B12D4F0 for <>; Thu, 13 Dec 2018 00:38:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G-Vkr_JIiPDp for <>; Thu, 13 Dec 2018 00:38:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C1D1128766 for <>; Thu, 13 Dec 2018 00:38:32 -0800 (PST)
Date: Thu, 13 Dec 2018 00:38:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1544690310; bh=6sBWb9D1SZdkcguo876zVvJ3EUPlRcVXUFR/EAbrSTA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1HaPJlYmSDQqtlrCMJxurpJAAhXUNbaWLPjuzCcUE2H+dPFGhCFOKqsXOjnnzIAhj 6qlroWCXw+HPjZCwXqbPe3dV95maaJ5v+Qyf5P+/WAbhB6Idj7ZSAoJmWxuUB7MVSN An9W0FcgsFChMm7sXvrLvF1F2cSEWHM+srPrrOo4=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2132/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Provide guidelines on token validation (#2132)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c121a8698301_2bc63fae58ed45b8857897"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2018 08:38:35 -0000

> What do you believe are the principles that we should be applying here?

I believe this requires careful analysis on especially possible attacks - some work is already happening elsehere.

These are just my immediate suggestions, but I'm sure I'm missing something:

- Tokens that pass integrity checks and which have not expired are accepted and require no further path validation, but must be treated as failed integrity checks if reused within a short time frame. (This may not work if a client retries a connection attempt with the same token - so clients can retransmit a packet with a token verbatim, but not reuse it in a new connection attempt - some would retransmit with a higher PN for RTT estimates, but I'm not convinced about this in context of attacks).
- Token integrity checks should include verifying that a token was created by the entity controlling the endpoint and that IP matches, but due to replay this is only a minimum requirement. (Since a client can have multiple IP's and both IPv4 and IPv6 on separate paths, I'm not sure it is that simple?).
- Tokens that pass integrity checks but have expired either due to a built-in timestamp or due to an old validation key grace period should be treated as a missing token, forcing new path validation. A server might have a grace period for old token keys during rollover, if it still has the old key.
- Tokens that fail integrity checks should result in dropped packets unless the server has lost state, in which case it should ignore the token (or perhaps issue a retry if the token is not already a retry token?).
- Tokens that cannot be verified due to server upgrade or other loss of context should be treated as a missing token, forcing new path validation, but only for a limited grace period after which they are treated as failed integrity checks. This period may be different for Retry and NEW_TOKEN tokens. If a server does not eventually drop packets with invalid tokens, it is vulnerable to attacks. If it always drops invalid tokens, a client might never be able to connect. (Perhaps a client should be advised to drop all tokens after a few failed connection attempts?).

There are probably some simpler underlying formulation that can be used to condense these guidelines.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: