IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Wed, 30 October 2019 21:22 UTC

Return-Path: <ekr@rtfm.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 76C53120A4D for <quic@ietfa.amsl.com>; Wed, 30 Oct 2019 14:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 0mfnD3oMmipg for <quic@ietfa.amsl.com>; Wed, 30 Oct 2019 14:21:58 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 F3E57120A8E for <quic@ietf.org>; Wed, 30 Oct 2019 14:21:57 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id 195so2738846lfj.6 for <quic@ietf.org>; Wed, 30 Oct 2019 14:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vRYfa/JW4XX/f3Eoy2K7a2SEhWh9UcOnKZUR9nxjolk=; b=VfESEk4V/yubzZqhqNHNMfCk0zuvcmLHSng6hvLOYiz/UVFdIBDhsHjdCxX5D2SVd8 aAiUPA4PJF67KAIToixApizI0ivP7diHaZ4wMdcBzCwyGmU5rfH355pW0EH81Tw5TDTV 6Rc+lGm+GHW/nYg9jHmSmusaifPvvThJNyvRRbPey/Jcw7TMfZEVi8jW0/O8+SeH3PHk JFZKiiHkbOJOnFBwIXvOLuaU+JsgLaa7xx2t3uoTIxy8cAfS3s3RyqNDG8dpN4JGA03W D3WLjeRGmQhr4UdLQb4hK+OkOywQothR9PhOgjsq9OEe7Vn1bV08V9WbBGuLnrw8Qp9V 3HyA==
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=vRYfa/JW4XX/f3Eoy2K7a2SEhWh9UcOnKZUR9nxjolk=; b=oroaBcSGOyMwswnFtinRTJq4gsWlDTrrLH5S95AqsZrJrJJKcnC3Fzvd5YFaxUeZx2 d94UqkJc0fWzjjSMrO4p3SvRjtiKPHG5gMeJYj2z0GsT68eQc3+xkMyHEsDZIy76Qlwy MUJCgb6R/vN71wTdPLiVFTcc21ODEt4maECUJ4Z29N0vg/SLXVgqAPucDTgkUmSFchoP QCLl5EMk3y1/v+1QuvQUjHAbBy86QfsXPGLG1wgI72FDA2Y+KDh4KoHAFJxXdyMCq1hp LfcgcHk0sCvIFT8WKPGczDQ44mvuG/xFnov1RU3VGTddtnbXPisW46AozMqpYgo4eBix NNBw==
X-Gm-Message-State: APjAAAWLsoo/l+OZBpbA/B2JXKA/t7O8KOK6pYLkCtBFO+itsJCJQ2dT QuomabsNDHhG4SQ/wddCKPUL+Dsp0n6jS/+ZX07TGg==
X-Google-Smtp-Source: APXvYqxbLMRsUqqNU5Lls0RbsPAfoVd8hCXGLjsGM68vAg4tQIg41fs+2gNwmdxdnk5C5hY8YvL/+Zw4Rorgzi2rGFo=
X-Received: by 2002:a19:f107:: with SMTP id p7mr195169lfh.91.1572470516313; Wed, 30 Oct 2019 14:21:56 -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> <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>
In-Reply-To: <CAN1APdeNFGuZh5gX0MBC-CotdSeHzrHk7jqUtZJKyCcFMc2aew@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 30 Oct 2019 14:21:19 -0700
Message-ID: <CABcZeBO_af+CZZse+-WpjRQWj35UjRpvZMTq0_wCGoMBQE0Z2g@mail.gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: Martin Thomson <mt@lowentropy.net>, David Schinazi <dschinazi.ietf@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, Mike Bishop <mbishop@evequefou.be>, Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008b862205962752c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_2wDSz0FcWEyRdgW9GhNj1G_KRI>
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: Wed, 30 Oct 2019 21:22:01 -0000

On Wed, Oct 30, 2019 at 2:06 PM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
wrote:

>
> I'm going to stop here, because it seems that you're assuming we don't
> just keep the keys indefinitely. How does that lead to deadlock?
>
>
> The problem is that having keys indefinitely leads to various problems.
>
I've heard that asserted but I'm not so sure.


> If the goal is to decide when the handshake is complete at both ends in
> finite time with high probability, then it appears that an explicit signal
> is required because you cannot rely on random (organic) 1-RTT traffic to
> drive this process.
>
Well, it's not clear to me that one needs to know this, actually. I agree
we've used this as a proxy for various things, but it's not actually clear
to me that we need to, so we should re-examine those cases to see what the
real preconditions are.

-Ekr



>
> -Ekr
>
>
>
>
>>
>

v2.23.0 | Report a Bug | By Email