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