IETF Logo Mail Archive

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

Mike Bishop <mbishop@evequefou.be> Tue, 29 October 2019 18:26 UTC

Return-Path: <mbishop@evequefou.be>
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 3FE1C120B50 for <quic@ietfa.amsl.com>; Tue, 29 Oct 2019 11:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 RqtyMgNhvB2l for <quic@ietfa.amsl.com>; Tue, 29 Oct 2019 11:26:53 -0700 (PDT)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720109.outbound.protection.outlook.com [40.107.72.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2B0120B61 for <quic@ietf.org>; Tue, 29 Oct 2019 11:26:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUAWKIhJeiiF1HTXOdnoQJBWCFkevY6Ze3kr6hejHie59tIF9i2rq5x4Sk4ONBWqevEjeYUK8ImfD4JX2nVE3JSqgV7lsZ8DnDnwMSVcQ7uplQrCNOKK2eu+IXzcmYkvMlBm4Z2Lb62WoTDdZJcJGeyZ7CnM2/hy18KRc2YzuwdZadXbDh3F2ddL4y/Vm28vbu0+qpWu/yssldfvvAlEpZgRy4vzbN1gqgwZhVwyIylqEZ8BKU/vcqi3pyM9ihPsBWKUmimB0KgSBoRMG3zquVQtUJRn8Pu4Y/9guqwS/10cxMXIndSWgACt8FNraML30NcSpq12tCDm9Pbfy1w70g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XKlsvaMF4rsAhxdAFzjeY7BslCswAihlc7tUEwhIBc0=; b=KNt1oF4WTs9W62DJ2RYwHjV9e/PHewCVuE5wUjC2xqxhUMN1ygdXycIJz45fYR4DI7zm7ywIJwSVEUX7vTgBTmyd3DqjxhG6JSTBH6RTl1fxTJGVFfue2Q6z4XtJ39TDINbJ4l/N/o4mx39PR9NUz80Zzzdc0YyZcsCGAdJlTHvajBdRvPYtV2Ef43mUB24dYP1iebUgsNeHnX/yCDbAvgJ9epFq0p31Ap/d5DdMJkmikoFmWRAvufIcmFyYv59nhw/6HNkIBfYVVkN4uqKSGHbBNkc7+7g+z/hTA8cW5bPLWohx7ho8nTMZECedqWZMWWzNqkEvmbgGPQx3cRdt4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XKlsvaMF4rsAhxdAFzjeY7BslCswAihlc7tUEwhIBc0=; b=EAZIB/IEsweSS7uyj/uVcfthmQ2wlWRA1YjYpYdyM8JmI2PO533ubu6pz6lXtst9yLlfp7ZrfKyRsAljn+wmC2auzGM9gIPo3dpfVd38X7mC/uINzQNvmvM7nJuqbtH7mzP+gUoi1/uPmPjcAKx6amMeM+5omPID4RJbvAsHqTo=
Received: from BN6PR2201MB1700.namprd22.prod.outlook.com (10.161.152.144) by BN6PR2201MB1427.namprd22.prod.outlook.com (10.174.90.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Tue, 29 Oct 2019 18:26:39 +0000
Received: from BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::c92c:4b04:cfcd:655]) by BN6PR2201MB1700.namprd22.prod.outlook.com ([fe80::c92c:4b04:cfcd:655%7]) with mapi id 15.20.2387.027; Tue, 29 Oct 2019 18:26:39 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Eric Rescorla <ekr@rtfm.com>, Martin Thomson <mt@lowentropy.net>
CC: Martin Duke <martin.h.duke@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, David Schinazi <dschinazi.ietf@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Consensus Calls for Transport/TLS issues, post-Cupertino
Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino
Thread-Index: AQHViHGZIuF5g6IoEE6LYrhgawqNGqdl3+KAgAACSQCAABB9gIAAJugAgAAEuICAACuwgIAAzYuAgAF9CnCAAIMlAIACfAKAgAOQaICAAD7ngIABXIYAgAE7BRA=
Date: Tue, 29 Oct 2019 18:26:39 +0000
Message-ID: <BN6PR2201MB1700E30A73DA3E8E91937C6BDA610@BN6PR2201MB1700.namprd22.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> <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>
In-Reply-To: <CABcZeBMdQPMeu862uizQYKr451Y9mvwhZ4MT7h_te5ho_Y9DOQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2600:2b00:931f:a301:6877:8be6:ec8e:e92d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d3ca04d7-0352-4d0a-3a28-08d75c9d8a2b
x-ms-traffictypediagnostic: BN6PR2201MB1427:
x-microsoft-antispam-prvs: <BN6PR2201MB14274C8F8136EF445DE45BB1DA610@BN6PR2201MB1427.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0205EDCD76
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(39830400003)(366004)(396003)(199004)(189003)(51444003)(14444005)(6436002)(2906002)(7736002)(53546011)(102836004)(6506007)(6306002)(229853002)(508600001)(6116002)(25786009)(54896002)(9686003)(790700001)(236005)(256004)(55016002)(14454004)(6246003)(52536014)(74316002)(5660300002)(54906003)(110136005)(71190400001)(316002)(8676002)(33656002)(99286004)(66446008)(81156014)(66574012)(64756008)(81166006)(486006)(4326008)(7696005)(71200400001)(76176011)(66476007)(76116006)(86362001)(66946007)(46003)(476003)(446003)(11346002)(186003)(8936002)(66556008)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR2201MB1427; H:BN6PR2201MB1700.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jlVuWdFu4+NBMHP6R0b/C2zK/9pQohfWuhsIRFfAktNtpY/gRjrsDXljlYddbwY629HNU8foZCeU7YxE6UPLxwo/ZanQaHqVuGxGcMPWTshIQ1MPtXVIgmTu+FmmbunAu6wI6ouHGF0bC3qsbTLHFbpoN1vfJYhHUFY6T9dblnNMqXjyRs6M/6Uxe8fYy1jr6L73+PJi2/96FVrDBB69ojsvqH1+bnwJvXpVJlWhwgcLj81QGtaQpIhyqv8NHKune5m/Kr3fK9QD1fiBULu5psxBN7ucrhg5D88TPOidAAXT6QczGaTvFHJSNqpQW4fNhT9HC7P4ccaGddhEo3meJONK8grB2TkwVfuxOrZXbCNabLdzs/vZ0XoqnuFu8x2bdqchO7yFglD9Zs/hSINLKsKYmAs/4X8CjANbMOCU1JOOZIOBTxV7b4RDA+N0RJ0m
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN6PR2201MB1700E30A73DA3E8E91937C6BDA610BN6PR2201MB1700_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: d3ca04d7-0352-4d0a-3a28-08d75c9d8a2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 18:26:39.2674 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qfjPV9THi5pyo5ie4usbtouLFWC0CJ3hJ/4+HIz212R4Xg3s7IPVtOmB6wcMa6gOsGVDkNrTgaDSMRFhwQ33bA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1427
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NAhdkAl6Hmxx17o_ajdc2-s-ecQ>
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, 29 Oct 2019 18:26:56 -0000

Let me make sure I’ve got things in the right order here: things “just work” if both client and server are actively sending 1-RTT data.  The server knows the handshake is complete when it gets the Client Finished; the problem is that the server doesn’t know.

Therefore, ACK works iff we know that the client sent something ack-eliciting in 1-RTT.  So one solution is to require clients to send something – anything, really – in 1-RTT immediately after the Finished.  When any 1-RTT packet is ACK’d, the client knows the server has confirmed the handshake.  A client that wanted to be cautious could simply send an immediate PING, or PATH_CHALLENGE at 1-RTT along with the Finished, and they’d get their ACK.  (This only works if the server is doing the right thing and not reading 1-RTT packets until it sees the Finished, however.)  Requiring the client to send HANDSHAKE_DONE would have the same effect, but require it instead of permit it.

Alternatively, the server could send HANDSHAKE_DONE, explicitly declaring that it has received the Finished.  Receipt of the frame is all the client needs, but the server needs the ACK to know when to stop sending it.

From: Eric Rescorla <ekr@rtfm.com>
Sent: Monday, October 28, 2019 7:34 PM
To: Martin Thomson <mt@lowentropy.net>
Cc: Martin Duke <martin.h.duke@gmail.com>; Jana Iyengar <jri.ietf@gmail.com>; 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>; Kazuho Oku <kazuhooku@gmail.com>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino



On Sun, Oct 27, 2019 at 7:47 PM Martin Thomson <mt@lowentropy.net<mailto:mt@lowentropy.net>> wrote:
On Mon, Oct 28, 2019, at 10:01, Eric Rescorla wrote:
> I think we're clearly going to need to spend some time on this. I don't
> think the spec is satisfactory as-is: we should be designing a
> transport that works for all use cases, not just H3. That said, I also
> don't agree that we need an additional explicit signal. We have one,
> it's called "ACK". We should figure out how to make that work.

I think that we've established that ACK doesn't work without something to push it along.

No, I don't agree with that assessment.

-Ekr

v2.23.0 | Report a Bug | By Email