Re: [TLS] Don't Split HelloRetryRequest
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 01 April 2021 18:24 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357243A1E2A for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 11:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tcdud.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 D-ddVM9SBnQl for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 11:24:23 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2102.outbound.protection.outlook.com [40.107.20.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83723A1E23 for <tls@ietf.org>; Thu, 1 Apr 2021 11:24:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mwm+yfs7fJKvkgkSGVDXQSOImy0ZTxNE2VhocNuO4qPBAoElcJ0k/b4LhXL5Q9LOMGrjNJLyQ9fF2jMomFULhzIMzfm/eROk0qU9DreOmsNkH4lrV321IAUaWajYU62NLkLCZnUvVFHtQuLm92oB3yZescKSHbLEM3ILoh0kxEPJcKkRoTY8uVr1AD2XSZpV4XOBMC0AHjehDH48IyfxdZamIdqmACczbPpTZsLz9Qpu3nuxbmjRCem7dFgDnLQQCYaeUJN4a9/f2mn7DW/WKmvPZxgmtkN/mDVslsDUMPbO9bqt7LUso1kwVSsEpDpraKYV5luuByLu6Jko3XayiQ==
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=xRgKXLOPjvAPmuJnIb3+Qqck5iMYscyIGU0yqrc4ykA=; b=eQzei5hRDF0QCp3CleehWveouyarvQFp78njP4rtAjJNYYa9kjvrwHrvFx/7CGt4f/oQcna47F98M5T8XBgCgg/8vKAyUeYnpqtiDM7sdGSz0fgN2yu8rgSdGmuA5dFK5oAM3BPgO3QDhwPS9By82+WVieoYlF2RDCaQ4fGCPk+T3is2L20XvHFghgPIzkXUfSFFjOcQ0dkFHKwCaKLT0aed583/Ub7BvjUFNPWAucA285Z5oKFZP+qVPOLlTwOP3nZAVp/6ScjePR/RsczkKuc+i2b9dLCDw6GdlNlormEhZLyDtNx75OB5XFDMHj/Z8uPb6O/5oE5Z4eJK2Yux3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TCDUD.onmicrosoft.com; s=selector1-TCDUD-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xRgKXLOPjvAPmuJnIb3+Qqck5iMYscyIGU0yqrc4ykA=; b=AU8gO8RDPGLlm4NBGXat36sWDgUQzLuJ8xAJqz7Wxi8danmTRksqdrQuZZ5vTAhueE0bLP9LqOiY/sHeVEBOFYeKi9sJp4sLzpy5xGVy1Td9C9gDCPVHtSu7bVmA0X29Lh9hnv247+bXfD00IOTJIexQpqkWb2DLD+xRGjLx45g=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cs.tcd.ie;
Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB8PR02MB5673.eurprd02.prod.outlook.com (2603:10a6:10:bf::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.28; Thu, 1 Apr 2021 18:24:20 +0000
Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::2d8d:9193:d3f3:6cc6]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::2d8d:9193:d3f3:6cc6%5]) with mapi id 15.20.3999.029; Thu, 1 Apr 2021 18:24:20 +0000
To: Christopher Patton <cpatton@cloudflare.com>
Cc: Martin Thomson <mt@lowentropy.net>, tls@ietf.org
References: <d0758a0a-737b-40ac-8189-1b4168510859@www.fastmail.com> <CAG2Zi216sYnwmZFdHxnMC+8vP0Ewr7tBr0TBc2PKkpJsgRFjiA@mail.gmail.com> <8f69f37e-b011-85a3-cd76-75cff00156a2@cs.tcd.ie> <CAG2Zi229wAWC8NLuN_1h6KQiBRzxvA-NQN8obdoSbfAUL+713A@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <c7c8a7fe-143d-cb50-8806-7eb052588e84@cs.tcd.ie>
Date: Thu, 01 Apr 2021 19:24:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
In-Reply-To: <CAG2Zi229wAWC8NLuN_1h6KQiBRzxvA-NQN8obdoSbfAUL+713A@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="UpKLEOj632he0Fq3EzlUMYaemvUHZ0VlI"
X-Originating-IP: [2001:bb6:5e5e:b458:705a:4d69:e974:1604]
X-ClientProxiedBy: DB6PR07CA0204.eurprd07.prod.outlook.com (2603:10a6:6:42::34) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [IPv6:2001:bb6:5e5e:b458:705a:4d69:e974:1604] (2001:bb6:5e5e:b458:705a:4d69:e974:1604) by DB6PR07CA0204.eurprd07.prod.outlook.com (2603:10a6:6:42::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.8 via Frontend Transport; Thu, 1 Apr 2021 18:24:19 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5a74cfb1-aa86-45c9-74fa-08d8f53b5dd9
X-MS-TrafficTypeDiagnostic: DB8PR02MB5673:
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-Microsoft-Antispam-PRVS: <DB8PR02MB567307156CC78222DAE26372A87B9@DB8PR02MB5673.eurprd02.prod.outlook.com>
X-TCD-Routed-via-EOP: Routed via EOP
X-TCD-ROUTED: Passed-Transport-Routing-Rules
X-MS-Oob-TLC-OOBClassifiers: OLM:1148;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: XS4Shgrqm6/YIVOPz65bH4pa4oOpYtv466VVYE47Jmaib//ZSRNyDHWx3geAoIsdZFlok3Ot7xeLuk74XQgCZEc8prtqGEU+pulij3dN9p3EkX7AayXNWb4+cgEYsUZQGCcQsBBsusgWJB+5Z0xaKt8Iwhc4Qd6wVZm2SrVzF8vcpRQAgmeQApma9baBpv7K+NUF8Kk/Hpy/idMDsC7aE+B0kOMe1la4fMjeQWIWGsKDuesniBFlmU/aDO2sDp9Ek5jrmI8E3P1Vl+BcGtPqwo2mgoIDgxqAH1AiLFkrzUAWbESYtuP4wusVfdE7Ghlwg+flZTCyjAkfaUXoKP0kcb2mZUD55U53E1mkgcZWywDhDZC16kYGUKX58dIW/2OJKBDMLjFJXxN8vTb+PdgyYonQ7C/dOf8MLx7vR3aQkB8qmoS72LSWreVU/059nsUspEkjXgbKCU19LvvX1T9gM9ynLRjPzfqXjlAQXtRbgk3720DarirrhDvycGAOVcMsBFIklSDo0uvZpe+5gUGZDGKIWlv9h6JhBOts60xEKhENwDWgCrDn12A8Z75j09/GszmgW5Kh0dADyk+lcKYCGcSnRaKZ021/D5qdM2YCa3uv28h5tUF+wMZ/3wrKHCZpmwWLFvPykZljurnu7lEOUUjDR/fdZHZBJzrbzidUtVs3Jh3JoIW1sccbBFdJvnSxzr98blQ013XgQnHkj1wCoQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(396003)(376002)(39860400002)(66476007)(6916009)(316002)(786003)(31686004)(5660300002)(38100700001)(86362001)(2906002)(8676002)(8936002)(21480400003)(4326008)(83380400001)(66946007)(66616009)(66556008)(33964004)(6486002)(235185007)(2616005)(478600001)(16526019)(186003)(52116002)(31696002)(53546011)(44832011)(36756003)(45980500001)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: kfc3+/LIfTW8iAsa8Q3z5P2zaOX9UIuBgjoxL2Syj2OGMsnl+KqUsWiHjn9wWFKkSd6TMiaeSlHCBOYyZmurY9JL27D0rARSKbUKdJrJAZr8+JDkQnRN7/qWvxV5ArLe91cKwtSLxYkDqY/owljJc9N2B/ULAuVNmVdnVxZLJxY5J0BNveM7L2Pmabo/HxxUktwPyBPIXB8T9qgXd0FOQC9aHraWEj/yVlLU5FVdoBUaoXY4marwbWfrEyfpGCMAfWastA9CN4ySQTS+wjbdxJS2iPfKH0l8wYjUUVf7tj+H0fbmee2VmVnwPf5+Tk0z1U1xs7WR+R7/wj+uipJaQrvpgQTZqktnwQfb31+Ce7AedYzgeO8siEF3ZJeDxUgwBzBOI3pt1M5Dg9+IXGypxxlxh3iBZIoi3WGXgGPefbzKipA0t3VLkiufC7yEQ6SeyKXYX1AcCNyACBFNlRGnincMk4NLNp7UyFIwgUtNQx49vkEpDdMpJjscIKpb0SM23Z7fvwVzS5AM4TOE+o9fL83vW2qbqcnKmMjdM/WC4BoKEGx/XH4IqB6i4vfwezdRnFXz7Ianf1kV1aFbu9DABAbDAZzkSaYcJZrFpde1feAsMpcEESMDEVChx/lvw2843/JJHfxeyI/tuv/UlB8QxbGMxuZPOj+eM6dE9JoKncm/MGRtqdWWKWmDuTdECa2c/G7MIvVYwzURMfYiy9SxjCC0Hyc1B2bjq6kpIEczfVYEk9MziA3AfETlXiilZtvc2rUYU6NbO7HeirrtaHkbu5sKP1cywOJFir6jNpKnXyTKtSQdO+/M9wLf+NaMi+oYS64wj6q/C3aSrogvQOQkbV9gS5ZSqmrYH2RCUwXnmKHwE8bIf1L+2Q0sMIOh28ZlnaCtToFSBALZdmi9m644BdMKg4Tz/GkdQfg7V23Qmv72nGIFML1XKDPY0/ycNc0bVgqorgA2nfQDyLTJ8ZnCQParXaAVD/ZTuh75BDcByH/dr+0TXKnB0dyA5jbmQoODIBnldSgHzUYDs2Tt9MoMxQ/94qQn/VDDrr2JshEplkPxkUmVEj/l8sBhhKv2QunkDdtUwGp3ssrjLwWxbXHZXX4/S+PpH+/Z6Q8YIBOD7H+9e01qNQLQLKjxNwSvNMxxD+TiKnvG2eLPJY701BiN/T1Usfe7f9Oebts+YEaH4ODaII6Em2Ergy4A59cCUmFCCpMpWWzjtiswD2cBJmMdxXSLvnATQ6yBErLuisxr/2kz+gswOoLoDmXzXVMOf5ouC5vG6sXXhJEf2pNgQMl3HpArihpNHs9NQCUkx+bJCZ+uoOxf+IA50bmey7Cf/3jq+GAFHARqNtWi3NRSgA9tbXK5ao1pSaPZIKJjeFBlazQ4EFv7FKgzYNs93hYm7M4r
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a74cfb1-aa86-45c9-74fa-08d8f53b5dd9
X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2021 18:24:20.0272 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vGfx+V+wBN6apOQRcV3oAKyIsQ7g9oHosdmpmsiCPwwldhm1KbJ1k3IlrzPtsHgJ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5673
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/egDcCrTjOvjc3uyQVia6OgGer5U>
Subject: Re: [TLS] Don't Split HelloRetryRequest
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 18:24:29 -0000
Hiya, On 01/04/2021 19:13, Christopher Patton wrote: >> But let me ask a question meanwhile - how often does HRR >> actually happen and could we not just let ECH fail in a >> bunch of situations that would otherwise require all this >> new complexity? >> > > One way HRR is used is in case the client's and server's cipher suite > preferences don't intersect. This feature is an essential part of TLS, as > there's no a priori reason why the client and server will initially > advertise overlapping preferences. (They usually do, hence the claim that > HRR is rare.) I've seen that claim and kinda suspect it's valid but my question was whether anyone had measured it? > I don't think aborting the handshake instead of HRR is an > acceptable solution, as this would mean there are deployments with which > TLS couldn't be used. No. At worst it might mean that there are places that need to do some config before TLS+ECH will work, but that's true already - they'll need to publish an ECHConfig anyway. I really wonder if we could not achieve as good an outcome much more easily with some guidance on checking your front- end's choice of curves and failing when some of the HRR cases get out of whack. (There'd still be some work to do for ECH as we can't as you say get rid of HRR, but there might be a lot less work/complexity.) Cheers, S. > > Chris P. >
- [TLS] Don't Split HelloRetryRequest Martin Thomson
- Re: [TLS] Don't Split HelloRetryRequest Stephen Farrell
- Re: [TLS] Don't Split HelloRetryRequest Christopher Patton
- Re: [TLS] Don't Split HelloRetryRequest Stephen Farrell
- Re: [TLS] Don't Split HelloRetryRequest Christopher Patton
- Re: [TLS] Don't Split HelloRetryRequest Christopher Patton
- Re: [TLS] Don't Split HelloRetryRequest Stephen Farrell
- Re: [TLS] Don't Split HelloRetryRequest Carrick Bartle
- Re: [TLS] Don't Split HelloRetryRequest Stephen Farrell
- Re: [TLS] Don't Split HelloRetryRequest David Benjamin
- Re: [TLS] Don't Split HelloRetryRequest Stephen Farrell
- Re: [TLS] Don't Split HelloRetryRequest Martin Thomson
- Re: [TLS] Don't Split HelloRetryRequest Martin Thomson
- Re: [TLS] Don't Split HelloRetryRequest Christopher Patton
- Re: [TLS] Don't Split HelloRetryRequest Martin Thomson