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

Kazuho Oku <notifications@github.com> Wed, 30 October 2019 01:25 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 B9087120059 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 18:25:09 -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 VudpxK_A_Sx5 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 18:25:08 -0700 (PDT)
Received: from out-11.smtp.github.com (out-11.smtp.github.com [192.30.254.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C7512003E for <quic-issues@ietf.org>; Tue, 29 Oct 2019 18:25:08 -0700 (PDT)
Date: Tue, 29 Oct 2019 18:25:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572398707; bh=mLTB1/aLYmzxIDz9b38SoYUH5wYSk037qCmedAeRbBo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NDmye43mS9bNzpfX3O5kd0Iq1kLSy0ufNuf8g48lgiG79GIKpy/+hCnrcFcbGObK9 oeCKiJFSUbuHeNgg+0rzSUoOJzfxsSNGcYIZekKEU8mZ5zLiqrCrXfSfAJ70LOqOle BD8XNJAZHZl1RRDojhjsBD0KjptFZWAvcPNVvt7E=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7VVFZUHI3TTGWMF2N3YYMPHEVBNHHB5HRKFQ@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/308921376@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_5db8e67365d2c_14113fa74b2cd9681890d8"; 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/MwceCfPOeGTpwTV27OCmLe_2ryQ>
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 01:25:10 -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

@DavidSchinazi That's obviously the case. Thank you for pointing that out.

I think what the PR fails to state that a Retry token needs to inherit the properties of the NEW_TOKEN token included in the Initial packet that trigerred the Retry. One way doing that is to embed the NEW_TOKEN token in the Retry token.

The reason why we need the NEW_TOKEN token to be embedded in the Retry token is not only because there is an attack that you describe. It is necessary because when the server receives the first Initial packet from client that carries the alternative version, and responds with a Retry packet that carries that alternative version, and the client in response sends an Initial packet that carries the Retry token using an Initial packet with the alternative version, the server needs to extract the alternative initial salt (and other information) from the Retry token.

I'd update the PR to clarify that.

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