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

Kazuho Oku <notifications@github.com> Wed, 30 October 2019 02:30 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 DC4361200A3 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 19:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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, 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 erbots6KK1Hh for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 19:30:55 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E0612009E for <quic-issues@ietf.org>; Tue, 29 Oct 2019 19:30:55 -0700 (PDT)
Received: from github-lowworker-d31a065.va3-iad.github.net (github-lowworker-d31a065.va3-iad.github.net [10.48.17.70]) by smtp.github.com (Postfix) with ESMTP id 431AB52083F for <quic-issues@ietf.org>; Tue, 29 Oct 2019 19:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572402654; bh=Sskxc9mOkMSYhqV6wWf9i8bIzhsgr33K9dO0m23F3+E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QiEfIWsIQfxDxa5Ilalor0lg/OhnzlX81mRfkOoCLHy5uMxLMCO82wSD5Sk97M94T IKXjBjQCVftNEFGhtrvgGEXC0IV59zca2KKKSy0uJcTgnuvPIcHm4FXosETAF/RWOd vGPXfnmUDCMFEvvYPGO6oVyLQY+9a8m0TWxLBc/c=
Date: Tue, 29 Oct 2019 19:30:54 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4SZRX54T7OXKLA2ZV3YYUF5EVBNHHB5HRKFQ@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/308935443@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_5db8f5de353ba_5d9a3fa720ecd96410976b"; 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/TmJSVK3vOHWsjX9dV7A-7TTaRJk>
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: Wed, 30 Oct 2019 02:30:57 -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

@martinthomson I think the design principle behind this PR that I have are:
* passive attack does not reveal the payload
* active attack can lead to the payload being revealed, but is detectable by the endpoints and thereby disrupts the handshake
* handshake falls back to v1 when the server forgets the token encryption key

As I think the issue pointed out by @DavidSchinazi is addressable (see my comment above), I think we might stick to the principle and how it evolves. If we conclude that the design based on the principle is simple enough, then we'd be fine. If not, we can consider the alternatives.

-- 
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_r340407134