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

Kazuho Oku <notifications@github.com> Wed, 30 October 2019 05:35 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 BC36A120089 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 22:35:37 -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 KTNd4w2J4xja for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 22:35:36 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0752712003E for <quic-issues@ietf.org>; Tue, 29 Oct 2019 22:35:36 -0700 (PDT)
Received: from github-lowworker-edec459.ac4-iad.github.net (github-lowworker-edec459.ac4-iad.github.net [10.52.18.32]) by smtp.github.com (Postfix) with ESMTP id 550CCA0C4C for <quic-issues@ietf.org>; Tue, 29 Oct 2019 22:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572413735; bh=b4z00mcAIg40FLDcniAN3eI8xYMXGiqXX0UK2OLI8hM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kO32WxePiOG3aP6RIVsVK1mINRe5vaku634U9BNCAXEVrhHA8t5LuHnO5HrLMjxE3 oookOfDerJGCmsQRxfIoIp1s2kc0vueBcYQMSu3WuImI7e2gZrFgb/WxtmNslo50Ha JHQTQAS1sK+YUstlx+iQs/1ZxNe+EPbbVC/jmqR8=
Date: Tue, 29 Oct 2019 22:35:35 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ7BSLL4W25WH5WKQF3YZJ2PEVBNHHB5HRKFQ@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/c547745701@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_5db9212745740_4d6f3f9aabccd960822f2"; 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/Ll2Qy99hYY4ng9VgZrGPoxASSEs>
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 05:35:38 -0000

@martinthomson 
> This is a whole lot easier if we force the server to commit, because then the server has to manage the fallback case. It makes this more brittle, in the sense that you need to make the static key more durable, but I think that it would be reasonable to expect a server to do that. They probably have to manage session ticket keys in this way.

I agree that it would be a much easier if we require the servers to commit.

At the same time, I think session ticket encryption keys are not something we should compare with. This is because the impact of losing access to alternative initial salt leads to handshake timeout, while the loss of session ticket encryption key merely leads to a full handshake. We have had this discussion in ESNI, and we ended up adding a fallback (i.e. esni_retry_request) due to a request from one of the largest deployments of TLS. That's why I have so far thought that a fallback is necessary.

That said, it might be possible that we have different requirements than ESNI.

After all, this alternative set thing is about giving the servers the *option* to issue different initial salts to every recurring connection. A server that advertises an alternative set does not need to work that way; deployments that might lose the key can issue a static initial salt that works across all the connections, and that would still be a win for us.

Considering these aspects, I am tempted to drop downgrade from this PR and see how it goes.

-- 
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#issuecomment-547745701