Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)

Kazuho Oku <notifications@github.com> Tue, 29 October 2019 21:52 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518FD120112 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 14:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXi3JhvSYoSt for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 14:52:43 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247D612001E for <quic-issues@ietf.org>; Tue, 29 Oct 2019 14:52:43 -0700 (PDT)
Date: Tue, 29 Oct 2019 14:52:42 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572385962; bh=v40GC+DdEvuJcCOJ3dH+Xa55WOwT4wYtXcrme2J3DdM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YpUKk3T8BFbg1vZ4d7iotZGBhVREOMLDWzEhq8Ovu60B7uccEuIptKZzfu44hqsca jkzzOvxBl7F8CxUatO3WrvPbmvNsS6VbbgkVJPYEGfALmLoYSXZef2EbVJbkZzMcHF JAHDNNzESMrgGI++HNOfFTCKr2VYzvqIKAE9Bm4Y=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5PQEPDVDL6KOKAPHF3YXTSVEVBNHHB5HRKFQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3166/review/308858136@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3166@github.com>
References: <quicwg/base-drafts/pull/3166@github.com>
Subject: Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db8b4aa24e5d_b7b3ffb1e4cd96c19967f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/9f3dPllMGUAjMBbpMJSbO4Gmz7s>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2019 21:52:45 -0000

kazuho commented on this pull request.



> +NEW_TOKEN frame, the server generates the alternative initial salt by calling a
+pseudo-random function, embeds that initial salt into the token which is then
+encrypted, and sends a NEW_TOKEN frame that comprises of the generated token and
+the alternative initial set.
+
+When the client reconnects to the server by using the provided token and the
+alternative initial set, the server first checks if the version number field of
+the incoming packet contains one of the alternative version numbers it
+advertises, then if that is the case, applies the corresponding packet type
+modifier to recover the correct packet type.  If the recovered packet type is an
+Initial packet and that packet contains a NEW_TOKEN token, the server decrypts
+the embedded token and recovers the alternative initial salt, uses that to
+decrypt the payload of the Initial packet.
+
+When the server is incapable of determining the alternative initial salt, it can
+send a Version Negotiation packet that instructs the client to use the default

This PR has a built-in downgrade prevention mechanism.

The requirement we have in this PR is that each NEW_TOKEN token that the server issues is linked to a particular alternative version number.

When a server receives an Initial packet with an alternative version number it recognizes but with a token it cannot use, the server sends a VN. The client reconnects using V1, but the text in the PR requires the client to continue using the token. Then, when the server receives the V1 packet with the token, and can in fact use the token and finds out that the token was in fact being issued for a version other than V1, the server generates a VERSION_NEGOTIATION_ERROR.

In short, it is a downgrade attack if VN was issued while the token was usable.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3166#discussion_r340344021