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

David Schinazi <dschinazi.ietf@gmail.com> Tue, 22 October 2019 20:06 UTC

Return-Path: <dschinazi.ietf@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 85A421200F3 for <quic@ietfa.amsl.com>; Tue, 22 Oct 2019 13:06:48 -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 Lif_fPTVyQsH for <quic@ietfa.amsl.com>; Tue, 22 Oct 2019 13:06:46 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 47F16120077 for <quic@ietf.org>; Tue, 22 Oct 2019 13:06:46 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id y3so18556348ljj.6 for <quic@ietf.org>; Tue, 22 Oct 2019 13:06:46 -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=bKbb177bT8VoaewjqpBSP+HAYOHi+OdJHBRsNI79EWY=; b=GdZtirkAyQDSVlbQDv2HJv4oP4fnez9rfS9M6CgpCV7szdnyrb4sFnnyTs+Pvdq2yn BAAAjKnwcRudIJMKaCeO+jx5KcgLVJ1xNXL73hYbPuG20QfupypLeWILba+vr3xC6qu6 WrEPt77e7w2Oq/vqPhJk0ka4Bfm5bOf0TuuUAOvi2fq4c3rDdqNcfoNBzQH79a9+8Lg2 ItXkDYapkoKICKts3mqyZbB/PC1n12dB3yBbhcqR9uJdgty6a3IeNMgA+RM/eaBSTz36 d2FthMYrjeKzzVIWt0qFpGGeWsKLRaCYtCsboGgEajIzbSuBIG0tbHKjDcroofJWcuvK ampA==
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=bKbb177bT8VoaewjqpBSP+HAYOHi+OdJHBRsNI79EWY=; b=cy76WWj+7qbKkBsGb2u9SbvMYJ4t4nwO2XDQdJ1cUK1yA2aLiwI5FBUiZdWM0ie1tj iXdLguejc8XrLSXlOrGVvC+6dWc+xYMprAOSzYM4SpqdpXKHFhR8Addem0XqPdia6fRd N70QOzOnD3y5cg98QlDSBFX4GHRXVmGlrWVuf2RhpRllyUQr/xj7G2YIVBxm1WJzPZwE rWEhhD+KQGDi4mG5RK53MJYeogWea2/fiPDv/87uSjPuDoBoYPqcZpJ5V1Psre4Oo4Z7 t8AlaVXIhRpNQe8NWJTwvvfam1xfx8zPTo6aQBmZHfYbB+2itvsEiEgRkiF3wZqTDel8 dogQ==
X-Gm-Message-State: APjAAAWN8GtYPKVQRmuDco7/9qpmthbz0ShqLUHKV/GrL4cJ400M08Ba GwG59qhtpaEuRbvHLLxjiVuV6qqw2R4oPB7zbfI=
X-Google-Smtp-Source: APXvYqxAVp9Lo2BdDv+mtZLZ4tVFGvodMZ4BXye8jRqntz93HMghkD04tjU354iUeJAbdA979VmfAcuvE0GfNsc+wf8=
X-Received: by 2002:a2e:416:: with SMTP id 22mr3417147lje.55.1571774804430; Tue, 22 Oct 2019 13:06:44 -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>
In-Reply-To: <CACpbDccOe01VBjwwy=mdSi5nync8bXa506OMTbLPpBH-hoj4Sw@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 22 Oct 2019 13:06:33 -0700
Message-ID: <CAPDSy+4S06qHBbitdH07Ah6gJYV+ZMY4huYLVGw14Q-n6isCrg@mail.gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
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>
Content-Type: multipart/alternative; boundary="000000000000e2923605958556e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pgXCFrU6M5QaDamekLs6ChfODww>
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 20:06:49 -0000

+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
>>
>