IETF Logo Mail Archive

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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 22 October 2019 05:14 UTC

Return-Path: <mikkelfj@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 DAF4F120AFA for <quic@ietfa.amsl.com>; Mon, 21 Oct 2019 22:14:35 -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 F9BvtpYF2mWy for <quic@ietfa.amsl.com>; Mon, 21 Oct 2019 22:14:34 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 C8BF3120046 for <quic@ietf.org>; Mon, 21 Oct 2019 22:14:33 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id r1so6576466wrs.9 for <quic@ietf.org>; Mon, 21 Oct 2019 22:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=fWcih5TOR/GH5k4neOrkM3y9DwhbM2Vt8WENriHKBtY=; b=sHIBYCqMcPWr5Ei0gZwrgSAJUsf5jb/8PxFODapS5Z46/5xR9b2gqjnBr/lK7uA+sH pFgjN3To122gqPY4eAz0J8co0uEo1qKEmph9aZDXp2RAa985CYvhxe4OjbZDm6yopcOj ZUU4Qh7npIV7ibVpYWP3Fk3VtkXwYoVYxCKRwA7/AWoaZKJraJ7ypalYo5mhEfUmCJnx YMDPj2+pxqGV+iPAtnp2zCVVz8XDNDIHyjrcDVb/+O3y718bs3x0QIYDNIEt74Lh5aN8 pUD2GpYXMdg5MwkOAXCTu1RFTA9kAgNzKAAjB0kPfummNgzCpyxGsQt9p+5Fu0QJA3HM BvKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=fWcih5TOR/GH5k4neOrkM3y9DwhbM2Vt8WENriHKBtY=; b=mFqSkQfeRnasrHc1TR0aIe/s19/t373ZirbhSochXTon3ILMw0CIOSsLmVmr21KPw0 BLZCXWKCTihVEPjWuPytDpVcDvmc6zCUkfXEDb2+ghQ2Vj7+2IBG3HklEHgkLMm2ptNB dOg11ouuP+94MwE3K12oqwT7oSP44tbftsXw/H40f+BKbP5nnbdqqkoCZeQy3oMw40X2 GOw2dWB6/j+7UfNdUPrOBzE728v3qUZ859rEAvH/6VcRNJPuBdhWh1qM/0DAFl1ydj1j ietGdrL38tC/tBXM9fRZZ86DsyuMx3C4iuLmFvDD3qwx7qYfOxTz9RLrkDEVgKqGQgk1 9zZw==
X-Gm-Message-State: APjAAAW7BTfVWIb3mm+xwbarR8+SwdVar2MxswyPzfQH4TdMnDajT1lf x9f7yRzvTTTcULeaEjsJ7MO8QF3X
X-Google-Smtp-Source: APXvYqyMOow1ui6+p+TQpi9r9Bzo/iKg7AwLLaKy/akIkcV4erVLol018/1Xm8yyaykSsZCTOb4UZQ==
X-Received: by 2002:adf:f2d1:: with SMTP id d17mr1452735wrp.353.1571721272265; Mon, 21 Oct 2019 22:14:32 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([2603:1026:6:38::5]) by smtp.gmail.com with ESMTPSA id 65sm12617962wrs.9.2019.10.21.22.14.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Oct 2019 22:14:31 -0700 (PDT)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>, Martin Thomson <mt@lowentropy.net>
CC: IETF QUIC WG <quic@ietf.org>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino
Thread-Index: AUNGRDRGcAHxOVcuLp0Y9BVrwR+CR3cyVXYtMDVDMTBlZGU0NVE1YTdXmZSbGlc=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 22 Oct 2019 05:14:31 +0000
Message-ID: <DB6PR10MB176678E88FF226C2EB8FF78EAC680@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net> <CANatvzwYA-NN+p5jLu4vpgKY_G-ZoUM03CacZWS2FAPyPqgiiw@mail.gmail.com> <BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680@BN3PR00MB0083.namprd00.prod.outlook.com> <22517ab5-9a6c-4486-b7ea-03badc064cbe@www.fastmail.com>, <CANatvzx=RWB1Bio7tqX7nN_Vn1SfSaE69LZbuiU5pWeXP=BwNQ@mail.gmail.com>
In-Reply-To: <CANatvzx=RWB1Bio7tqX7nN_Vn1SfSaE69LZbuiU5pWeXP=BwNQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176678E88FF226C2EB8FF78EAC680DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rW8m7-lGtTqTBH9nf_R1VsXZh38>
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 05:14:36 -0000

Without a way to move to a single PN space I find this a deal breaker. I might do a custom version of the protocol.


________________________________
Fra: QUIC <quic-bounces@ietf.org> på vegne af Kazuho Oku <kazuhooku@gmail.com>
Sendt: tirsdag, oktober 22, 2019 6:58 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Consensus Calls for Transport/TLS issues, post-Cupertino



2019年10月22日(火) 11:38 Martin Thomson <mt@lowentropy.net<mailto:mt@lowentropy.net>>:
On Tue, Oct 22, 2019, at 12:39, Nick Banks wrote:
>  I'd also prefer to fix the problem, even if it means bringing back
> something like RETIRE_KEY.

I would prefer to think of this proposed resolution as a temporary one.  I don't think that we agreed to keep the handshake keys indefinitely, only that we would use that option as a fallback position until we found a better solution.

I might point out that #3121 is not proposal-ready as a way to resolve #2863. That is because it does not define how to send and receive Handshake packets until or after migration happens. There would be a deadlock unless both endpoints agree on how that should be done (e.g., how to select SCID, whether the path used for Handshake packets migrates too).

Without that being clarified, can we say that we are ready for a consensus call?


On that basis, I think that it would be best if we open a new issue that says "Handshake keys can't ever be dropped".

We might still conclude not to address that issue, but the important thing is to ensure that any solution works properly.



--
Kazuho Oku

v2.23.0 | Report a Bug | By Email