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
- Consensus Calls for Transport/TLS issues, post-Cu… Mark Nottingham
- Re: Consensus Calls for Transport/TLS issues, pos… Kazuho Oku
- Re: Consensus Calls for Transport/TLS issues, pos… Nick Banks
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- Re: Consensus Calls for Transport/TLS issues, pos… Kazuho Oku
- Re: Consensus Calls for Transport/TLS issues, pos… Mikkel Fahnøe Jørgensen
- Re: Consensus Calls for Transport/TLS issues, pos… Jana Iyengar
- Re: Consensus Calls for Transport/TLS issues, pos… David Schinazi
- RE: Consensus Calls for Transport/TLS issues, pos… Mike Bishop
- Re: Consensus Calls for Transport/TLS issues, pos… Jana Iyengar
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Duke
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- RE: Consensus Calls for Transport/TLS issues, pos… Mike Bishop
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- Re: Consensus Calls for Transport/TLS issues, pos… Watson Ladd
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- RE: Consensus Calls for Transport/TLS issues, pos… Mike Bishop
- RE: Consensus Calls for Transport/TLS issues, pos… Mikkel Fahnøe Jørgensen
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Mikkel Fahnøe Jørgensen
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Mikkel Fahnøe Jørgensen
- Re: Consensus Calls for Transport/TLS issues, pos… Eric Rescorla
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- Re: Consensus Calls for Transport/TLS issues, pos… Christian Huitema
- Re: Consensus Calls for Transport/TLS issues, pos… Martin Thomson
- Re: Consensus Calls for Transport/TLS issues, pos… Christian Huitema
- Re: Consensus Calls for Transport/TLS issues, pos… Mark Nottingham