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

"Martin Thomson" <mt@lowentropy.net> Thu, 31 October 2019 01:44 UTC

Return-Path: <mt@lowentropy.net>
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 2E62C12008B for <quic@ietfa.amsl.com>; Wed, 30 Oct 2019 18:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=KLbq9KrT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GTAmBn2C
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 4xBcGfUOpyAi for <quic@ietfa.amsl.com>; Wed, 30 Oct 2019 18:44:50 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F3412006B for <quic@ietf.org>; Wed, 30 Oct 2019 18:44:50 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C7CBF223E6 for <quic@ietf.org>; Wed, 30 Oct 2019 21:44:49 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 21:44:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=iJzge3cdpI8rcuFkA8Tb/Nesw8TAjsS G+AlOOFxpPng=; b=KLbq9KrTcCJBoI+w7bREeA48r4kD/J6t0ZBHll5rgWo2dY8 I5q2HkhbJ/a6b4X60VO5AFzPZ3C1XeAv1YVFYLjIxFXITr5JbADChrTRMa7A1nob e3+kQf68HI1pknTXHD9kz2mfnEx4o+GwyYwKekS4y8Pv14LF9MwxzrJS3WSDvz6p rTaTFHF3Fev/CWXw0RcXL+OM+JmUldq1XHBbLu+MH38xqqLLbh/Xj7ktpz7y/DJ9 7xXBFgoVGhO2qLerlkEvHZTyXo6ogP70ThVrBFhZwYDHtDyXOncxlonl44gGdqDv IGE02nvSnMm6a60bkUL39Yqv+cQ5otppfsQV8hw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=iJzge3 cdpI8rcuFkA8Tb/Nesw8TAjsSG+AlOOFxpPng=; b=GTAmBn2Cx6KpED+nu6CJKf XygQEFKvxtM6hQxAPkJR8jYDGbND3UUp99TzzKJQMqr1WTEcAqxJD4erknSOUEcS 74EPZYSGu6gg+gCu/Z5eabP9l4CciRVwd0QloWqxSmzMXhxmDt8zjvhs4VdhnJI3 UFEOFhPqUeXP4B9MHmBZUI2sbWy00vPbaqir+XtyOoLZ9cmc9dTEwHCRtO1d8jXo zt7FYhkwVL83iOf/Xhw18IswyZv8gftH9BNQQ5TMgnBJOXXoxtrpVPlrFzAqtk2X Ubd83EjDUFL7Q0IGSU6keAjSGNfCxpUtwCjbYoZm6sp+eJ0EVzqN9dTdGsmrHCCg ==
X-ME-Sender: <xms:kTy6XcIXJqseudrlXs1xk874VTc7Srio3KJB5hLCmTG495AvJQsq4w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtgedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:kTy6XTlhOu2RPC_MM_jSMl3giLUB9cIRrMFqJSUG8AxgNxv7WYpeww> <xmx:kTy6XaGjPrhe6uZ77VW1tz-hQgGAEqVRAGBkTDaBHurOVeRchO8Uuw> <xmx:kTy6XTHV5BiIJ-GEnzugE_qTkymXD0KzAB-5nWX7BzOXNaN7-qmLPA> <xmx:kTy6XT9jxMs0bxiGC-jvQb_1yBeVMZAvWNDPXNhj5kTNFx9uOLNvmA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3C06CE00A3; Wed, 30 Oct 2019 21:44:49 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <536ff4e2-ccf3-4a83-a071-da5bedd3a8d6@www.fastmail.com>
In-Reply-To: <bfc301c4-8730-aace-6ba8-ae9fd5760105@huitema.net>
References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <CAPDSy+4S06qHBbitdH07Ah6gJYV+ZMY4huYLVGw14Q-n6isCrg@mail.gmail.com> <BN6PR2201MB17008576E4F8400B5DDB696FDA6B0@BN6PR2201MB1700.namprd22.prod.outlook.com> <CACpbDcf+n47NXh8XMEKx6n1fiJPZ+WyuivNmuBy1vKhZYZe6Uw@mail.gmail.com> <CAM4esxQYyTQPpF13v0AT4R=TcFOa9=UCn0nWsiqwMReYFOYDYg@mail.gmail.com> <CABcZeBM2QGC+wx-UUKMkJDqxKscOgJfhqwPhr7QXg3h-GpZwfQ@mail.gmail.com> <4d408d7a-7c50-4ccc-a42b-fb2b71b0c507@www.fastmail.com> <CABcZeBMdQPMeu862uizQYKr451Y9mvwhZ4MT7h_te5ho_Y9DOQ@mail.gmail.com> <98b890c7-d57f-484c-88d5-056e4e607465@www.fastmail.com> <CABcZeBP4BwBsySd8Phhg3fd3kTMoS6E=j5tit3pg7JKe7vrb6Q@mail.gmail.com> <1e5ae15f-56cf-47c5-930a-9f5bae59763b@www.fastmail.com> <CABcZeBP2yHXaaXYtAwYfqshrENwMaMCQsmnOd3KD2DurwGy8dg@mail.gmail.com> <CAN1APdeNFGuZh5gX0MBC-CotdSeHzrHk7jqUtZJKyCcFMc2aew@mail.gmail.com> <CABcZeBO_af+CZZse+-WpjRQWj35UjRpvZMTq0_wCGoMBQE0Z2g@mail.gmail.com> <3d4976da-b03d-469c-9242-4073d88048e3@www.fastmail.com> <bfc301c4-8730-aace-6ba8-ae9fd5760105@huitema.net>
Date: Thu, 31 Oct 2019 12:44:30 +1100
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7LRIe7jqarp2rVLT_PP2DVLUhkk>
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: Thu, 31 Oct 2019 01:44:52 -0000

On Thu, Oct 31, 2019, at 12:32, Christian Huitema wrote:
> Migration is only initiated by the client in V1, so waiting for the last
> handshake ACK on the client side is good enough. But key rotation could
> be initiated by the server, and doing that before handshake confirmed is
> a bit problematic. 

I don't see how this is problematic.  Handshake packets use Handshake keys, so they aren't updated.