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

Kazuho Oku <notifications@github.com> Thu, 17 October 2019 17:37 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 4897C120B30 for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 10:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DB7PEGLueIjk for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 10:37:16 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B781200DE for <quic-issues@ietf.org>; Thu, 17 Oct 2019 10:37:16 -0700 (PDT)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 5A06E9601F3 for <quic-issues@ietf.org>; Thu, 17 Oct 2019 10:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571333835; bh=RRtAmmwlU4XVVun52WLEY2jb+NBUXh2t3HRMxJwrUtQ=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Rdw/pl3n/6hNmnVXM7TcJ6sep2iGHKayjiv6doTk4xLYV6xtehoOV3cfwrhHzoNzA 3fyIip7jfcqVI2/7i27W6mpg3cL9JKg49w3jj8QbSCTITJ6K3aGWv91PH2Xn4n6hU/ 1w4cldrMJ6usOVvwS0uSNYtb/i1GLO8w6yWODLmc=
Date: Thu, 17 Oct 2019 10:37:15 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7G7J4OV6UQ5IHAD5V3WXTVXEVBNHHB4UHVOQ@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@github.com>
Subject: [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_5da8a6cb4b71b_20b03fc9886cd9644074a"; 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/x8LnQSRd6QXNfAj7WRQQbMf--KI>
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: Thu, 17 Oct 2019 17:37:18 -0000

[Version Ossification] Alternative version and Initial Salt should be part of NEW_TOKEN

At the moment, PR #2753 suggests using a Transport Parameter. That approach has two concerns:
* We are creating another set of resumption information that needs to be retained by the client (we already have NEW_TOKEN token, TLS session ticket, and optionally H3 SETTINGS).
* We cannot have enough space for Initial Salts so that Initial packets would be encrypted (in the cryptographic sense).

I hereby propose (as a separate issue as suggested by https://github.com/quicwg/base-drafts/issues/2496#issuecomment-542889512) to embed the alternative version and the Initial Salt in the NEW_TOKEN frame.

Doing so solves the above two issues:
* The complexity is reduced, as the client can retain the alternative version and Initial Salt along with the NEW_TOKEN token.
* Initials can be encrypted and authenticated in a cryptographically secure way. The Initial Salt to be used can be different for each connection that uses the NEW_TOKEN token. Servers can securely store the salt being used in the token, recover that from the token, then decrypt the Initial packet.

As a side-note, ESNI for QUIC can become a way to generate the alternative version and Initial Salt for non-resuming connections. To paraphrase, this approach would give us the possibility to hide QUIC+ESNI traffic within QUIC+non-ESNI traffic that are resuming. This meets the requirements of ESNI (over TLS over TCP) that the handshake using ESNI should be indistinguishable from those do not.

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