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

Martin Duke <martin.h.duke@gmail.com> Fri, 25 October 2019 16:36 UTC

Return-Path: <martin.h.duke@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 DEFCF1208C0 for <quic@ietfa.amsl.com>; Fri, 25 Oct 2019 09:36:20 -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 9x3Ioy_bQ0yf for <quic@ietfa.amsl.com>; Fri, 25 Oct 2019 09:36:19 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 04D17120219 for <quic@ietf.org>; Fri, 25 Oct 2019 09:36:19 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id q13so3032181wrs.12 for <quic@ietf.org>; Fri, 25 Oct 2019 09:36:18 -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=u9QgNEnx4+PRg67aqqiej3SLndQIor5fqHi7GAN5S9k=; b=pvFAToNoG7EPbKAXQ/81SKgk1HOEJPSSEljquv5EYFnuCT10bW9hGWUZpGaec2rwKD 7/T+EGim8J88fZZKK69oFtl7EQDQG6MqlXoOSl3voNgjmgWBV27nyCfQuo6tyMeHDGZw 8vRN/xwBLAhqFoyioKZ+8Xdul5EXB1V9StBJZGzT70R1Q04YHMPydBQyU9usoOooK86o 7ELNaibP2WmbBGsf4sjlqMYQHFtnX94KABwqg3mzlQ8vZMdaPNHcM7T1W31hrjL2qvqN b7qlmFItotwCHLVZ/2xqzAFjMbU+U/k+rNFs0l6I1/h9jxRUHp5n0nr5JV6lJMGQ4XC4 gpqw==
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=u9QgNEnx4+PRg67aqqiej3SLndQIor5fqHi7GAN5S9k=; b=ufH5AumZiRPOICJxeVrIBdtdp1s/tV6gY1Oz1o8HLv29B3sQXVf8X2DADinX+j9qsz MSN34qGoEa1ActP4vIxwMYThTNQ9n0T+WFU12z8P8Q6Boi+M28Dbwy7LmNtYC0SSdwZh baWyGvi/AaRd4yK/tHwO3jPVkyzT+oqzqs/C5Qq4mpvWG5MFMrlmOQO9X42hDYmiXdao WeGuV99NZ0xHccqxkJiSOYz/iaTcnUqj0Uo3dpP2u935tUWVm9N3I2CNNyKtcwOMjkBn JPvCtkrkhsQU8/Cqvs0Hc3C+Mxvi1FIeA/jDOP4vizqA5qDXpZAMmQkwtUP51J0Ba5HL 4RDQ==
X-Gm-Message-State: APjAAAWsGZilcc5o92mHHOA7h6gcRy0kYVHdvC3UYIfmqzTNrzMv5OGD BoNnOVTdmTmtFiFLQF3Ij3HHZKAHR6+JJxme5WY=
X-Google-Smtp-Source: APXvYqyDNZhuq7tQ2QFtTczJUpma43E16n6j83c5fTEfxnmb3f+dY49Z5JkWhq64FxcvYpZOHZ5dhPetdXujVdwdqPk=
X-Received: by 2002:a5d:5282:: with SMTP id c2mr1317636wrv.64.1572021377452; Fri, 25 Oct 2019 09:36:17 -0700 (PDT)
MIME-Version: 1.0
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> <DB6PR10MB176678E88FF226C2EB8FF78EAC680@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <CACpbDccOe01VBjwwy=mdSi5nync8bXa506OMTbLPpBH-hoj4Sw@mail.gmail.com> <CAPDSy+4S06qHBbitdH07Ah6gJYV+ZMY4huYLVGw14Q-n6isCrg@mail.gmail.com> <BN6PR2201MB17008576E4F8400B5DDB696FDA6B0@BN6PR2201MB1700.namprd22.prod.outlook.com> <CACpbDcf+n47NXh8XMEKx6n1fiJPZ+WyuivNmuBy1vKhZYZe6Uw@mail.gmail.com>
In-Reply-To: <CACpbDcf+n47NXh8XMEKx6n1fiJPZ+WyuivNmuBy1vKhZYZe6Uw@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 25 Oct 2019 09:36:05 -0700
Message-ID: <CAM4esxQYyTQPpF13v0AT4R=TcFOa9=UCn0nWsiqwMReYFOYDYg@mail.gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Mike Bishop <mbishop@evequefou.be>, David Schinazi <dschinazi.ietf@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c84cbf0595bebf4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/VKYoRRjALrlrpX4lvSQ0vICQd4g>
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: Fri, 25 Oct 2019 16:36:21 -0000

I agree with the dissenters. The current spec works in the HTTP3 use case,
though I think we should fix it. Keeping keys forever is unsatisfactory for
several reasons. We should use an explicit signal, and there is no reason
to kick the can down the road. Let's just leave #2863 open till we resolve
it.

On Wed, Oct 23, 2019 at 7:40 PM Jana Iyengar <jri.ietf@gmail.com> wrote:

> Yup. We need to get this over with in the dumbest way possible.
>
> On Thu, Oct 24, 2019 at 3:53 AM Mike Bishop <mbishop@evequefou.be> wrote:
>
>> I think we’ve amply demonstrated that implicit signals don’t work.  I’d
>> like to see an explicit confirmation of handshake completion that happens
>> at 1-RTT.
>>
>>
>>
>> *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of * David Schinazi
>> *Sent:* Tuesday, October 22, 2019 4:07 PM
>> *To:* Jana Iyengar <jri.ietf@gmail.com>
>> *Cc:* Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; IETF QUIC WG <
>> quic@ietf.org>; Martin Thomson <mt@lowentropy.net>; Kazuho Oku <
>> kazuhooku@gmail.com>
>> *Subject:* Re: Consensus Calls for Transport/TLS issues, post-Cupertino
>>
>>
>>
>> +1
>>
>>
>>
>> I think the text we have in the spec today is better than the proposal to
>> never discard the handshake keys.
>>
>> My preference would be to spend the time to fix the issue, and not add a
>> temporary workaround for now.
>>
>>
>>
>> On Tue, Oct 22, 2019 at 12:51 AM Jana Iyengar <jri.ietf@gmail.com> wrote:
>>
>> I agree with Kazuho here. The issue of migration was not one we had
>> considered. I was going through this with Kazuho, and we may have
>> identified yet another issue with handshake retransmissions and migration,
>> which is present in the current spec.
>>
>>
>>
>> Sadly, I don't think we can call this issue done..
>>
>>
>>
>> On Tue, Oct 22, 2019 at 2:14 PM Mikkel Fahnøe Jørgensen <
>> mikkelfj@gmail.com> wrote:
>>
>> 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>:
>>
>> 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
>>
>>