Re: Consensus Calls for Transport/TLS issues, post-Cupertino

Kazuho Oku <kazuhooku@gmail.com> Tue, 22 October 2019 01:31 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15621120AA0 for <quic@ietfa.amsl.com>; Mon, 21 Oct 2019 18:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Dt1P-W0GFzlM for <quic@ietfa.amsl.com>; Mon, 21 Oct 2019 18:31:25 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37CC120ABF for <quic@ietf.org>; Mon, 21 Oct 2019 18:31:24 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id y3so15339703ljj.6 for <quic@ietf.org>; Mon, 21 Oct 2019 18:31:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eHACB4/5NSWO+u866EyzTkFwN0tMRdmUc2SV4ZDRm9k=; b=QOB9IGZURXCbcGHrZHjbA4rALU831kM4maq3dRoL6T1EE9HL8zT1oInlh8UbXF7eCz jkmMR0vknCYS0CVlG9VQS+BmBRGnjZWXBaK5MXTbHILs2KxprW5lPOrfdRVi8/ha7eI9 ZfgDQtjS1nPU3/0xLyB7H1e/uoKtKHB/y7be1r6F+/VkuEXrEY6DGYJBI9at4fZt+dtM bvPAjhr1Y8xtAwi7uXXpxt67AA/1KMNJVVEihFmkqXqclFe/UQiLo/9msfSkk5MxpTTA D2aE3SrXV6Fhlcc3RlG07KDa+A0hg6QbY3ZFBZPu3ZoNLD+y7iC1ZJ27vKrDz2xn8aRO wJlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eHACB4/5NSWO+u866EyzTkFwN0tMRdmUc2SV4ZDRm9k=; b=Wd4GF3LxaWvd/nf3EsAnScCaPtJgzeXK4TYFOIcFtSiKt0LLAVgKKoTslZzto3XsHF SqRu8X2GdfKEN3cwFTfhsd4pzZL3wNLdZA1Q1XAaZH0xwKUtCbmbTqGLcWRIw6tQ3DYT 7DIwGwxOFnrC7vapLXQeMp6cr6qN3McDXwWgFH2glAR91/Q2XafXQ+246oRTk6FwENEb v1goO/OU9kGIcZ1z23Hd3wLxP89uhHZXn9UGuFR/7lpHulttrZC9Lmw/TjhsQndY3AeS 95WM7hKOEZb6liyMuudUWx1fq3RE/cYZG8v3+QDlc8qwwo416cStfbxsJOMZ4JwSLl9u yhrw==
X-Gm-Message-State: APjAAAXB6kkT7Gv2YuUUPsu5DHMi1Vtg+0KtTCDQ1HVgD2Yq50PMTcm6 z/yQHTmmkuOvHumvT2IzTB/vpyCiZZ0rOzAnA4hcmg==
X-Google-Smtp-Source: APXvYqzN+FuW3VdD3Y52qpvJN668foCixDfJz/3JPbrsodQ5M+sVJ7RNvOygK8ISXOMDcjjv2vixW3xXGCtX2Q2aLTA=
X-Received: by 2002:a2e:3c05:: with SMTP id j5mr17265942lja.24.1571707882950; Mon, 21 Oct 2019 18:31:22 -0700 (PDT)
MIME-Version: 1.0
References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net>
In-Reply-To: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 22 Oct 2019 10:31:11 +0900
Message-ID: <CANatvzwYA-NN+p5jLu4vpgKY_G-ZoUM03CacZWS2FAPyPqgiiw@mail.gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Content-Type: multipart/alternative; boundary="0000000000000dd74c059575c24e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/uyEnxdQH3Te9E2miHHZedXR-JjI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2019 01:31:27 -0000

2019年10月22日(火) 9:42 Mark Nottingham <mnot@mnot.net>:

> The following issues have proposals for resolution, and discussion so far
> seems to support consensus to accept them. If you object, please do so on
> the issue or in response to this message (changing the Subject
> appropriately!). Absent any pushback, we'll direct the editors to
> incorporate them next week.
>
> See <https://github.com/quicwg/base-drafts/projects/5> for the current
> state of issues in the Late Stage process, itself defined at <
> https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md>.
>
> * #3097: Is CONNECTION_CLOSE ACK-eliciting?
>    The proposal is <https://github.com/quicwg/base-drafts/issues/3097>
>
> * #3085: Stateless reset detection should be datagram-based
>    The proposal is <https://github.com/quicwg/base-drafts/pull/2993>
>
> * #3054: Label for key updates
>    The proposal is <https://github.com/quicwg/base-drafts/pull/3050>
>
> * #3046: Handling of Retire Prior To field
>    The proposal is <https://github.com/quicwg/base-drafts/pull/3096>
>
> * #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number is
> valid
>    The proposal is <https://github.com/quicwg/base-drafts/pull/3036>
>
> * #3027: Codes for frame encoding errors
>    The proposal is <https://github.com/quicwg/base-drafts/pull/3042>
>
> * #2944: Layout of PreferredAddress
>    The proposal is to close with no action.
>
> * #2928: Lift single-packet ClientHello requirement?
>    The proposal is <https://github.com/quicwg/base-drafts/pull/3045>
>
> * #2863: unrecoverable loss pattern leads to deadlock
>    The proposal is <https://github.com/quicwg/base-drafts/pull/3121>
>

I feel sorry but I object to the proposed approach. As I have pointed out
in my comments in #2863, not discarding the Handshake key forever breaks
our assumption that no Handshake packets will be sent or received once the
handshake is confirmed. We missed that there are these side effects when we
rush to the conclusion at the end of the interim.

Specifically, we'd be required to define how Handshake packets deal with
migration (does the path for Handshake packets change? If it does, how do
we fill in the SCID field of the Handshake packet? If it does not, until
when do the endpoints need to retain the original path?).

I think we should fix the deadlock, rather than changing other parts of the
protocol that currently depend on the Handshake key being discarded at some
point.


>
> * #2823: Do Initial secrets change after Retry packet?
>    The proposal is <https://github.com/quicwg/base-drafts/pull/2870>
>
> * #2741: Re-visit initial keys discard
>    The proposal is to close with no action.
>
> * #2152: Why does stateless reset have to be checked after MAC failure
>    The proposal is <https://github.com/quicwg/base-drafts/pull/2993>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

-- 
Kazuho Oku