IETF Logo Mail Archive

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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 30 October 2019 21:33 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 D368D1208F8 for <quic@ietfa.amsl.com>; Wed, 30 Oct 2019 14:33:21 -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, UNPARSEABLE_RELAY=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 n7Qey3O1Pu3I for <quic@ietfa.amsl.com>; Wed, 30 Oct 2019 14:33:20 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 135DC1200D6 for <quic@ietf.org>; Wed, 30 Oct 2019 14:33:20 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id w3so733004edt.2 for <quic@ietf.org>; Wed, 30 Oct 2019 14:33:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=tTmqvx2VE60E3Fn35HCGp0h9+BWTST49AXXu+bXfOvQ=; b=YKJ2L7bd3QjuRxcdvh2w5k22YBPTrzCqmk5+R2mIp5btT6Wp2VvsVvYfJdrMLz0QdQ A8N/onKYMAYPUoGoXY2AYI1HZHyCR104mmBl5sq/ohcGj0DKb14jUe6YxrWlb7bjpC6h RDgHB6BVGVxTxCXfCb82ICsdUME1zIz2evdyMsS1xssljaEbD9BV6xssWemXkNXA46lq /uV1fBeJpx9JqViyhG4Ib5qpFAM/KE7wfrBL/Phrjy6Hj+6lUp8wyN2rNJltFX523dnu B8ThEPO9DbUsTEJNwynniTQ9EngLzbjCSNiLwvbOZ7UGE6R3WXs09nIWFxCK4dZk3mrB qrZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=tTmqvx2VE60E3Fn35HCGp0h9+BWTST49AXXu+bXfOvQ=; b=mYQsnhsfodX6vEccZs597CD/leg0p80ZKqSthcNsYxryv0DL5TQ2S8DEij5rGLYjJs goghM2vTrewGmDVhtcBcoo4nfFhEQs6lB4+3T+rKJ3KfZKZZUFZ7hwkXwtlFuLQMDhNq 2L65ro2BdaloT3vgFjdNsjxZsiAAaOyQiiFVViu4F0oN8j5RLmPgfiebzeqE4wE0pCad B1egosrCTu/egqrnXLhU05/jY3TouuUAUgPjQViGl/fF2bxMf/T2I10bmAGaxcJxVpgh 1LaRsv/pA0EiMyLYW18TAtEiYvIMix/bvNS8oFJgQoJswfgHK8ud4AQ24A0mXAgYJizW oYzw==
X-Gm-Message-State: APjAAAXr/NUvFRSPmDNoVED7SyAv4eWfvo9cCeUIvBoWOLmrqfvZMtmX EpqwDGPxWxI+npyilTsqBfuK93xAsEgcgyOAv6o=
X-Google-Smtp-Source: APXvYqyk1mYFj1Y8V9WrafBRU5pgl0vC2AJS9gX0KotAWkzJ4yLZivxwFQrxWXUjMDLwPHb6HHLkYCEOizkiRg+rLXU=
X-Received: by 2002:a17:906:a981:: with SMTP id jr1mr372934ejb.255.1572471198631; Wed, 30 Oct 2019 14:33:18 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Oct 2019 14:33:17 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CABcZeBO_af+CZZse+-WpjRQWj35UjRpvZMTq0_wCGoMBQE0Z2g@mail.gmail.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> <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> <CABcZeBO_af+CZZse+-WpjRQWj35UjRpvZMTq0_wCGoMBQE0Z2g@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 30 Oct 2019 14:33:17 -0700
Message-ID: <CAN1APdcxvfjmzOvtdRWm5HXyyEmwAQYm2hYNCxmnFnUfgQJnGg@mail.gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
To: Eric Rescorla <ekr@rtfm.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>, Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, IETF QUIC WG <quic@ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, Martin Duke <martin.h.duke@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000036cc830596277bfa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/pMPvOi39SXSAcBLQ8dDYSKX3LBs>
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:33:22 -0000

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.

For one thing, I would be sad if an optimised implementation needs to
handle multiple packet number spaces. That complicates implementations
because you need to think performance through all layers. Of course you can
just suck it up an deal with it. Likewise, you can probably find a way
around path migration.

By compared to sending a single 1-byte HANDSHAKE_DONE frame, why would you
do that? To marginally simplify the handshake?

v2.23.0 | Report a Bug | By Email