Re: [TLS] Don't Split HelloRetryRequest

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 01 April 2021 18:42 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 96BDD3A1EAB for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 11:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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=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 UW8z3Xe0gbOz for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 11:42:05 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2139.outbound.protection.outlook.com [40.107.21.139]) (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 6A9D23A1EAE for <tls@ietf.org>; Thu, 1 Apr 2021 11:42:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nedLflzrJMkRpz3ZehKGyeW585knGnyHIKUmZnprfLBdbGX+MZ3SBbs/amQilgWrEDQk4UZ11ni3nnirCnxhnUkQ9DzeLeuntzizLhMR7o0lsu3eoPQENF+yl6FF2uJgWMRpSyqwPbSU81lKfisoU+26hpVe2ZP+jbOVt7Atrb42vie7iWWK3CfNdJuw+u4OP1ctZIRpzXXY7Cc/BetQFnGgEhy60bx5ovfWwbSdfdsvyUulz+lAjVZLvNMErMlsBVhm2CfftZAEPhrOYpI5ljZRj7NEVl8Edm2qWtRPJerq5QpTxJM62vgOPWGwcy1wTzM9QnRojBB62BhqPgY98g==
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=p44O+rShOOf8fHsX5caeHN+LPY9DOe8suQbZ/L0ZiG4=; b=TDIizCDwNSw+h2E8OTaAbDOL5uGJAbk9wgjU7TbCGwIIzVjSuzsV7iCixSBCCi1aD5h+Q4EmpEzUMTbsyKrFt0Sy9JMha9SC5TD0SKZCxr/tRFmZ3f7sdeX1qkjT/yi8HY02nqM4Q51aQZUGNlpVI+o8dlfA1/pUXknCs8W6+fnskfjtnKl7lLKqAf3yry89cn3pzg33lhQrhALmcvFijTNDCt1N7O2kS02d/GQWp74QNsA6oTyv2DhPOWIOsYmKI/RJI/k4iV/BOYuB4lHsCKIm21wEZFIOTHvZto7/w6qzYyGAUfyq3Qw2B9wax72wb+upEagVSGwvvNQV1Zr76Q==
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=p44O+rShOOf8fHsX5caeHN+LPY9DOe8suQbZ/L0ZiG4=; b=ctPxFiWe581VRB6v1h8lOhMMPGardUgoBUINeiRDhqtwmafzLS7FBGhBZWQ9oycU/Jy/bpGUCJ8pnaU5hfEKGsjV8ypmcPq3LnypbdfByYllCNHO7TouyEkIEkRB8SV8K56WK6+Djl7Z5qtQV0urDI4K8lNeNEHt83BEdO2k8S4=
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 DBAPR02MB6391.eurprd02.prod.outlook.com (2603:10a6:10:194::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.29; Thu, 1 Apr 2021 18:42:01 +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:42:00 +0000
To: Carrick Bartle <cbartle891@icloud.com>
Cc: Martin Thomson <mt@lowentropy.net>, tls@ietf.org
References: <d0758a0a-737b-40ac-8189-1b4168510859@www.fastmail.com> <38b1703e-5631-015d-c31e-9186b38666a8@cs.tcd.ie> <961AFCF4-02DA-447B-907E-78917A97CCDC@icloud.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <57317362-c9de-5780-bb64-b48d152b4eaf@cs.tcd.ie>
Date: Thu, 1 Apr 2021 19:41:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
In-Reply-To: <961AFCF4-02DA-447B-907E-78917A97CCDC@icloud.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5RjDwKeciOqZ2u91GnbNOiBHlUmB5v2hQ"
X-Originating-IP: [2001:bb6:5e5e:b458:705a:4d69:e974:1604]
X-ClientProxiedBy: DU2PR04CA0173.eurprd04.prod.outlook.com (2603:10a6:10:2b0::28) 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 DU2PR04CA0173.eurprd04.prod.outlook.com (2603:10a6:10:2b0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.27 via Frontend Transport; Thu, 1 Apr 2021 18:42:00 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ea02065c-1667-4224-8f29-08d8f53dd60a
X-MS-TrafficTypeDiagnostic: DBAPR02MB6391:
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-Microsoft-Antispam-PRVS: <DBAPR02MB639195CFB8FD3E05071EB806A87B9@DBAPR02MB6391.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:1388;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: wbTH6HGMOWGdMeuOn4diKL/tusgxG3AFPURQs2LEjJwKCyDf2h3b+5lmhJQPte6E6n3le/bTsaNXrCmf8IAbgtAHFlZz2RVonQ0PkkCgBogn47FvNpn4SQ7A6ik3/vu6b5T5AzT+cSzwnizaBg9eDgS0DF0kdijyI2+8oXjtpRjRMC3K429bW8sUXU2zGB+I7nsgQlnmGWVtBDx+RNFKeshQlGYBUEpvMPm8dTUlAwv1GNkwtbNyLOqFoohTYzmFFkHp9l/h+ze4Hcak/3zP23K9rCJ/omhkhAmXGDnBBm2klAKDAOjVNBCdeTlMaobkoejrtPoRmPVU+VPFiOe8Q+ViqYO63x84+BXVN4tGV0EsPYhkil5ZD1jL5ktAERAh+FelC4fFhz23ZzKeN6kDLfeLVsGaKkodTZ8mYGfQAWAHuQjzJ1ydH72/spSIms/Vka2pMND9dLT/KYheVccqDzCtielwqOyvJzJaMhHK8i5JOuYmZiKTmsY8MSkzUjR4hUFZJLc91Civ7StCvJzFv63Wu3KSTQc+v1KerbAS4msKRLVzSkS9bNywH6PubrfEckgN+BaJLO1gieQQd/tnB5OiezTZUGJMAfkNMYAoxkaBupjPld5YKf6m+PZ/oFRMsxuPqlPo+8iSX1iQFf9EjmTC22qtR1IH0w+uI7kvEYHZl5KO3fmHZMWkMdu3MMvfryfNtbSDGMFKCy7I70/i0kMIkpM3AalZNcPdKW1yBUbZAFijTsnU6PpP8c1jFcpIQUX/0pAsXNT5qHnguj4DvYb+RL3XEmLsywgk+ZyaGP0=
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)(376002)(346002)(39860400002)(366004)(396003)(31696002)(2616005)(33964004)(66556008)(316002)(186003)(966005)(4326008)(53546011)(8936002)(6916009)(786003)(44832011)(66616009)(31686004)(38100700001)(52116002)(66946007)(86362001)(16526019)(478600001)(8676002)(36756003)(5660300002)(83380400001)(6486002)(21480400003)(235185007)(2906002)(66476007)(45980500001)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?MFo2bW00aUFrdkt1VW8rQ0FXU1dmM2pTK1RMTDB2M1Z5SzBOWmFSSTNxc2ZK?= =?utf-8?B?WU1EZkxoNkZhL0YzajRBWXRIbjU5cnRIaHJQUzBVMGt2b1RtZU05NjdHenVt?= =?utf-8?B?Q0tVbnErc1BpQmJ0WWVnNjZpYndYNElXOFZNci9ha1g0bnpBeTlGRjRacXRl?= =?utf-8?B?R3FPVlFWUHd3QWlJbGpDODNaSllIYmhqcU9XcTY3TGg5Q3NMdktjZWFMZjlL?= =?utf-8?B?cE9KYmhuL3JyUCs5cVZ3SHdZd0FuamFHTlRmQ2VZOU5KVUMwK0xlREU3WFZ2?= =?utf-8?B?eHBYN3BVWTQ3cVZKMWlRajdaR3ZEckF4c0lSU21SUjUrVExsYUxUakk3Z29v?= =?utf-8?B?U1JDN3A0Vk5NZ2FKNDZSV0xPMmgyMzltZFhSS3h3WGlqU0I2UkdnbnlLNVRv?= =?utf-8?B?TGRPa1E0SmE2aVFCK0JQT2YvN0hqdzFHWlQ2b1RNUGl5dkovalNZSHJtTis2?= =?utf-8?B?QUdud3VMbkEyN3FsQ1MwR2s5OFoxYW5xTmc3bUgvU2x4SzdpN2UwMDNQYTJR?= =?utf-8?B?NHlXYWNBamRtMjVnZ0hnenNYVjl1UVhrZ2l4QytRRHpmaTZiaVExL2Z6NStz?= =?utf-8?B?b3d0NnMrS21vOE1nYWpZek1JTzB6cmlaejVDOU9OcjNkaHk4L0IzNFlnUjV4?= =?utf-8?B?RDFSM2c0QTk1aDVTQi9ObHhWSlcyWWp1U0g5a0hYZVZnUzU4QXNrZUlmMVUv?= =?utf-8?B?RWh2Qk8xMGhNczRRNFo2YWRaYnRFYmFDVlpLMTBseVpqV3kvZU5WYWVsYytv?= =?utf-8?B?ci9UTjBRNVJ1K0w0cnJYbWdjdTgvNS9XVEh3TklzT2ZoZnVFaEc0ejBSMmxz?= =?utf-8?B?Um1DTnB4SEpJSWZheWlyNGJpSzJiZGFmQ1ExL3g4c3RKeXlTdkVHSzVlYll6?= =?utf-8?B?NmZrbkowNm14dWtyWUJWd3l0enhFZnYvcXo5ZUFKS3F0bXdYUllVb0dhQVVw?= =?utf-8?B?ZUJvZ1IwRlNGOVlUNHlZRVRpcTQwREV0cFRRMkFuaFYrV1lrY2NaQ0QzbUty?= =?utf-8?B?VjU5VE85YUxOR3BPUG5vOWhDSmlvMTM0TVExMjNMZTZmWWlhUjkrcjdpQnVY?= =?utf-8?B?ZjRTMUdVYUZUYndnQVhPajcwYmVCbjNMaWhRTG94V2RCblRjK0JKeWVoVDBR?= =?utf-8?B?RWF3NVdOMHJlMlYzSkYrYzN4WXFZanI1cW1vRGpTMFJpeW12NXhJLzI3V0RD?= =?utf-8?B?bnRpS3U4OERkZ0JrUnV5SWltRk1mZ1dzTHRubjZ4c0tXbVhYWnRCSGlTUFMr?= =?utf-8?B?aUdzdFR5QmQ0N0hpWFc2bStCVFdxS1BpOGhrWERnaXk5OVMxYlJxeDdXaFFC?= =?utf-8?B?cGNmZDgwc0JQaHduYjFPMEE5ZjhlN2dFVHFmblZzRWszQ0g4OGZHSC9lZm9N?= =?utf-8?B?bURZdEtFYi8wS0Y0dFVMdks2bXNyaFBvTXlXb3g1b243U25lcW9HVDVTa3gv?= =?utf-8?B?N3BubGpxUXJXWTlGem9TdG0yVUdYY0syaWhJamlrRTQrVnpPdnZqRWcvRFBB?= =?utf-8?B?UVJNN0NmSXFRM3YxQkE4ajNBczBvKzlmMGhiYS9NZ05xNTBYWEZEaytSMlVq?= =?utf-8?B?eXp0aCt1UDVrclBQSnpMRVdOSno5TFpuTkUyYktEa0dGL21NZ2RkeEtzYllX?= =?utf-8?B?WnowTnBQRmpRTm0rMzRZeWc3enhLOUNPdWJpU1lHUk1JMXFhcDZBLzhKZHQ5?= =?utf-8?B?b1FEYVh5S09yTGNuQnAwbjVwN1FxcGJBZnFET05sV09aTWgrN0p3WSt0SHhX?= =?utf-8?B?MWQ4Ym5FWlMvNWlzdEVTd1JrZkxIQUpLTU5Hbk1lQStVUHUxVUE1ekpnZFVY?= =?utf-8?B?Y0k0RUo4UCtYdzFqWUxGTmVyb2ZTZTA2ejJnTlZxcEsvN1BQTDdJTG50SGVO?= =?utf-8?Q?PZXPaA91kN1Wq?=
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: ea02065c-1667-4224-8f29-08d8f53dd60a
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:42:00.7110 (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: bfRXUnslwxT0Ox4+8awOdic/RXq6z9/h37AwGEB9uf+SYOPPKy7SMbTU2/wSbSZI
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR02MB6391
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/n97inXkwKQcodr2lzVRbi2h3r2w>
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:42:10 -0000

Hiya,

On 01/04/2021 19:28, Carrick Bartle wrote:
>> I absolutely agree both that we seem to be almost happily adding
>> complexity
> 
> I don't think you have to assume bad intent (or negligence). Several
> people brought up valid concerns and we're trying to address them.

Hmm. I got an offlist mail on that too. I'm sorry
if I gave the impression that people's intentions
were dodgy, that really wasn't my intent. I think
it's entirely possible to have the best intentions
and yet to be too happy to add complexity. I've
done it myself loads of times in the past, and there
are even RFCs that show that;-) That is what I
think may be happening wrt ECH - we seem to be
forgetting that this stuff is inherently complex,
even in it's simplest case, and making it more
complex could kill it.

Cheers,
S.


> 
>> On Apr 1, 2021, at 4:46 AM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> 
>> I'm not sure I agree with all of Martin's remarks below, but I
>> absolutely agree both that we seem to be almost happily adding
>> complexity and that that's a bad plan.
>> 
>> S.
>> 
>> On 01/04/2021 02:57, Martin Thomson wrote:
>>> I just reviewed the proposal to split HelloRetryRequest into
>>> outer and (encrypted) inner. 
>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files I'm
>>> strongly opposed to taking the change.  It complicates the design
>>> greatly and unnecessarily. The existing design has some flaws,
>>> but they can be fixed more elegantly than this. (Apologies if
>>> this seems a little long.  I'm writing down every possible
>>> argument I can think of, because I can't guarantee that I will be
>>> coherent at the meeting.) # HelloRetryRequest Has a Narrow
>>> Purpose Let's first address the key question of what
>>> HelloRetryRequest exists to do.  It exists to ensure that the
>>> client and server are able to jointly agree on keys to use for
>>> the remainder of the handshake.  This is a very narrow scope. 
>>> Furthermore, the particulars of key agreement are public.  This
>>> is important as we can also say that all hidden servers need to
>>> use the same configuration as it relates to cipher suites, key
>>> exchange, and related parameters, as the results of negotiation
>>> are sent in the clear in the ServerHello. My claim here is that
>>> there is no value in protecting any parameter that might change
>>> in response to HelloRetryRequest. # Don't Seek Complexity It is
>>> entirely possible to imagine scenarios where an inner ClientHello
>>> has different preferences from an outer ClientHello.  While in
>>> theory we can construct a design that would support that (the
>>> pull request does this well enough), to do so only serves to
>>> increase complexity.  It does not address any real use case or
>>> problem that I'm aware of. If we allow for the client to provide
>>> different values in inner and outer ClientHello messages, then
>>> the current design means that the client is faced with some
>>> ambiguity about which of the two messages a HelloRetryRequest
>>> applies to.  If we try to create an indicator, then that leaks. 
>>> We could solve the problem by making the protocol more complex.
>>> Or we could avoid it. This problem is entirely avoidable. #
>>> Matching Inner and Outer Values When we get right down to it,
>>> there are a very small number of things that truly change in
>>> response to HelloRetryRequest.  And all of these changes are to
>>> values that do not need confidentiality protection. The draft
>>> lists three fields that change: ciphersuites, key_share, and
>>> version.  From my perspective, changing cipher suites, supported
>>> groups, or versions would be a big mistake.  So what changes is
>>> even more limited.  Just the shares in key_share. On this basis,
>>> a client that offers cipher suites, groups, versions, and key
>>> shares that are identical in both inner and outer ClientHello
>>> messages will always receive a HelloRetryRequest that applies
>>> equally to both messages. The only adjustment that is acceptable
>>> with respect to these fields being identical is the addition of
>>> TLS 1.2-only options to the outer ClientHello (or the removal of
>>> the same from the inner ClientHello if you prefer it that way
>>> around).  This is a fine optimization on the basis that accepting
>>> ECH represents a commitment to support TLS 1.3 (or higher).  But
>>> it is really just an optimization (the draft makes this
>>> mandatory, which is silly).  The client can therefore remove
>>> options from the inner ClientHello only if it is impossible to
>>> select them with TLS 1.3 or higher. For new extensions, if they
>>> define a means of adjustment or correction via HelloRetryRequest
>>> (there is currently just one: password_salt, which I haven't
>>> examined), then they too need to follow this restriction.   It's
>>> not an onerous one. Follow this simple constraint and
>>> HelloRetryRequest will always apply equally to both inner and
>>> outer ClientHello and everything works.  Conveniently, this is
>>> more or less exactly what the current draft says.  Almost. The
>>> draft currently allows inner and outer ClientHello to have
>>> different types of key share.  The way it handles this is
>>> terrible: it recommends breaking the transcript.  To me, that
>>> seems like it would only serve to open the protocol up to
>>> downgrade attack. Incidentally, I don't see a problem with having
>>> a different key share *value* in inner and outer ClientHello.
>>> There's no point in doing that unless you believe that these
>>> values leak information (they really shouldn't), but it wouldn't
>>> break this model if a client decided to do that. 
>>> https://github.com/tlswg/draft-ietf-tls-esni/issues/333 appears
>>> to be concerned about the cookie only applying to one or other
>>> ClientHello.  I don't see how is the case, so I'm just going to
>>> say that this is fixed by having HelloRetryRequest apply to both
>>> inner and outer ClientHello messages.  If the client receives
>>> HelloRetryRequest that applies to just one of the two, then the
>>> problem is that the client is faulty.  That would be treated as a
>>> programming error as normal (crash, open a bug report, send an
>>> internal_error alert, etc...). Then there are the things that
>>> more or less have to change in response to HelloRetryRequest, but
>>> really only because the ClientHello changes: padding,
>>> pre_shared_key, and ECH itself.  For those, we need to address a
>>> minor inconsistency problem at the level of the core protocol
>>> itself. # Addressing Minor HelloRetryRequest Problems We do need
>>> to fix RFC 8446 rules regarding HelloRetryRequest.  David already
>>> suggested some minute adjustments for that problem in
>>> https://github.com/tlswg/draft-ietf-tls-esni/issues/358 .  The
>>> short version is that extensions can define their own rules for
>>> how they change after HelloRetryRequest.  This is a good
>>> amendment, especially as it relates to extensions that are not
>>> known to the server. That tweak does have deployment issues,
>>> because the original rules have been interpreted too literally in
>>> some cases, but that should not affect ECH specifically.  Servers
>>> that have this bug won't be able to deploy ECH without fixing the
>>> bug and that's OK.  Other servers will only see grease. The draft
>>> currently mandates that greasing values not change after
>>> HelloRetryRequest, which will avoid this compatibility bug, but
>>> also reveal the fraud.  I can tolerate that small amount of
>>> leakage. # Avoiding HelloRetryRequest I think that Nick's
>>> suggestion for helping avoid HelloRetryRequest by placing hints
>>> about key shares in DNS SVCB/HTTPS records is a fine one. I see
>>> the arguments about this being about the configuration needing to
>>> speak for backend servers when the record relates to frontend
>>> servers.  But my perspective here is that you already need to
>>> ensure that backend servers have a consistent cryptographic
>>> support profile; adding a small number of frontend servers to the
>>> set that need to be made consistent isn't that difficult.  If
>>> this consistency is not possible in some deployments, that's
>>> understandable, but then it is an optional enhancement that won't
>>> be available to those deployments, that's all. Of course, this is
>>> an extension that we can pursue separately. # Conclusion I'm
>>> firmly opposed to splitting HelloRetryRequest.  I would like to
>>> deploy ECH and this doesn't really help with that. I don't agree
>>> that there is a problem that needs to be fixed with the current
>>> draft. On the other hand, I can guarantee that this change will
>>> delay Firefox deployment significantly (that is, for an
>>> indefinite period).  It would require rearchitecting a piece of
>>> code that is rarely used already (despite being a source of
>>> significant complexity) and replacing it with code that is even
>>> more complex and would include paths that are even more lightly
>>> used. _______________________________________________ TLS mailing
>>> list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>> <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________
>>
>> 
TLS mailing list
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>