Re: [quicwg/base-drafts] [Version Ossification] Alternative version and Initial Salt should be part of NEW_TOKEN (#3111)

ianswett <notifications@github.com> Tue, 22 October 2019 02:41 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 C472E120024 for <quic-issues@ietfa.amsl.com>; Mon, 21 Oct 2019 19:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 txh1Vg77y3UN for <quic-issues@ietfa.amsl.com>; Mon, 21 Oct 2019 19:41:53 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50FBF12004F for <quic-issues@ietf.org>; Mon, 21 Oct 2019 19:41:53 -0700 (PDT)
Received: from github-lowworker-f144ac1.va3-iad.github.net (github-lowworker-f144ac1.va3-iad.github.net [10.48.16.59]) by smtp.github.com (Postfix) with ESMTP id 9013B6E0541 for <quic-issues@ietf.org>; Mon, 21 Oct 2019 19:41:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571712112; bh=fHpuEF4uP9/QO/PHUm6yW2vG6atOL5mudX6PxKpSdAQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IPheq8LG/JqUwixNDi9KgLj/eufDdzWo8ly9J+54lBpFAo6Z4uHLacwXfX3xNI6oE 0yvwq/Rbf+JNworMbGlHydIoP6Bp7e7Z4ZOHdobxdko0Reb4Heu1yAH5cWUEJfUldi BIgQHX5+zfpYN/GqD1lHMGETyFqLkkW1EJg9QIfs=
Date: Mon, 21 Oct 2019 19:41:52 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY443ROEW5B2OTBBN53XOWQBEVBNHHB4UHVOQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3111/544784567@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3111@github.com>
References: <quicwg/base-drafts/issues/3111@github.com>
Subject: Re: [quicwg/base-drafts] [Version Ossification] Alternative version and Initial Salt should be part of NEW_TOKEN (#3111)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dae6c70812f4_2bd73fb1202cd95c1022cc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/fBoJFgQ-VdQNvPMj2TkKPz_xJ2c>
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, 22 Oct 2019 02:41:55 -0000

> @ianswett
> 
> > Aren't clients required to store transport parameters when doing resumption already, so this is moving it from one place they store to another?
> 
> That's a good point. I admit that the only one benefit of bundling the alternative version-salt is that the server can store and recover that from the token. That said, please let me reiterate that that is a huge benefit, as it provides the servers the capability of protecting the Initial packets from on-path intermediary in a cryptographically secure way.
> 
To clarify what you're getting from this that isn't achieved in TPs is that here you're guaranteed that when the client comes back with the version and salt, they'll also specify the Token.  But if these were in transport params, then the client might decide not to send the subsequently transmitted token with the version and salt or the corresponding token might not get delivered in time?

-- 
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/issues/3111#issuecomment-544784567