Re: [TLS] Don't Split HelloRetryRequest

Martin Thomson <mt@lowentropy.net> Thu, 01 April 2021 20:18 UTC

Return-Path: <mt@lowentropy.net>
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 B2AB63A2224 for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 13:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=TCl4boLb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NbrnZzBR
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 OL1SbxAa2obS for <tls@ietfa.amsl.com>; Thu, 1 Apr 2021 13:18:03 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3813F3A21EE for <tls@ietf.org>; Thu, 1 Apr 2021 13:18:03 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 921775C00A6; Thu, 1 Apr 2021 16:18:00 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 01 Apr 2021 16:18:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=AMhm5ZQxPUeq/u6Z+I76qqfY8xIb NTlX83IE16jRL1s=; b=TCl4boLblqXCmXDKigDrrptvCLsVBegaPVk2OAXRxL89 T7Wg/P8aBLLPwQbRs5qLEfqbajNLqNwV+eauaB9wAEx0Xd75KhLRIRieqCLjRVp7 F1jQhOwMspzUDuFFulGZ4239kAUzzS6G30vF7J4qQ7iQvjomjjx1Im6xFki8FAMB Mz+cySNrLMSovdHBeFljVz8kQP4+4n7GPbGF5TpbSqt2csiAOBjH8M0u3GxNNGe7 wDGJvPikV4FXv6KXmdsLImgKzls+PjDU/vcmbOSpE4gmzwiFiU+FZw7dCM4YS2yq W580oJ6Kl221jfPZ8sSoNkFz9CuQA/hP+PTMf8lZxA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AMhm5Z QxPUeq/u6Z+I76qqfY8xIbNTlX83IE16jRL1s=; b=NbrnZzBRaUlXLE1wdtiSCJ 0aOj0WEDsbgZrGmz6ZOO2BF63UoEW3d8MKpZOsilm7IhQLfvxbTvRlL6WnRJDbd8 zQNjNKmVoK4hN7y6abqial/uKpu+r+E17dF7Qp6gR3yEy4Bqcs/mRR/wv6K3D1g2 Avz1U6GMLt9ihzDV9DxKifpf8PksE/qVkUGfRXD1NsqMm1ybqCLaTMo+9Hoab7cV vZZoVXQE9+3UqyHir7qMJrgIAoo/Al/2JbOMhQn61yxqOrDJneBG0wJxPAAPrqxC 8nQDQlovmYdB0u4e+OTZ6WpUfsLFaVixgERqu+0gZQxPYZKdkVqO4PCv5/dPbm2A ==
X-ME-Sender: <xms:eCpmYLmVlYd8vBpLxmZdsEV1YTdHda5CTO749P9CHJysixh0R0L5HQ> <xme:eCpmYO0Rt9u0jbkhJlbx-Qseg85pbeLgZHUTjv7Fb4LVjc0wUvMhJd1WNP15OPtFn oZ1cfXS-67LZsE42BA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeigedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefgfegueefteejveegleegudehtdektdelkeevgfdtieegudej gedtffdvtdeikeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhtlhhsfihgrdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhht sehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:eCpmYBro6QojBqM4RzrGomJesvyc1fEUrSrIVWIZohovS1TpeJ2jCQ> <xmx:eCpmYDmb-pTBzDViJQ3O1lLV87sjswH15qokvADvKvwoOc3dPt1R-g> <xmx:eCpmYJ0R-Vhd8KN1YdYa_w-_QuDZIIWDqXK-WflAqd_iXtOexvsscA> <xmx:eCpmYGi1wEBP_d8qaHX3wrN4XAFYpJhn-CeBaXXAlTSXAXATcHQUbA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1C7D74E02B7; Thu, 1 Apr 2021 16:18:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249
Mime-Version: 1.0
Message-Id: <f5d8dd48-950b-478e-b05b-2e1e5a321ea0@www.fastmail.com>
In-Reply-To: <CAF8qwaBUp9OzmDGr0f74fGvyDyzB=VdOzYt2nUecoPC+CYebtg@mail.gmail.com>
References: <d0758a0a-737b-40ac-8189-1b4168510859@www.fastmail.com> <CAF8qwaBUp9OzmDGr0f74fGvyDyzB=VdOzYt2nUecoPC+CYebtg@mail.gmail.com>
Date: Fri, 02 Apr 2021 07:17:40 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "David Benjamin" <davidben@chromium.org>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aLo7LYIqE7XVOX8GgaXjjmiDl2w>
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 20:18:15 -0000

I'm going to briefly respond, but as this is a public holiday and I have no real desire to work too much, please forgive any radio silence that follows.

On Fri, Apr 2, 2021, at 05:56, David Benjamin wrote:
> This was a previous attempt at this, but it seems to have been confusing.
> 
> I do agree that having ClientHelloInner vs ClientHelloOuter differences 
> that result in different HelloRetryRequest acceptance criteria is a bad 
> plan: in general, I think a client implementation should be judicious 
> about which difference it exposes because each difference needs special 
> logic to make sure it's using the right set as you evaluate the 
> handshake.
> 
> At the same time, I worry that *mandating* it in the extension will 
> make this decision process tricky to navigate and get us in a rough 
> corner. PR #316 was trying to capture exactly this, but it seems we 
> didn't get on the same page. (Maybe we can now?) See this discussion:
> https://github.com/tlswg/draft-ietf-tls-esni/pull/316#discussion_r509880007

My claim (to be verified) is that mandating something is possible.  It might not require a simple rule (cannot be different); it might instead require that each extension be analyzed and have its own rules instead.  I'm confident that for the 4 or so extensions that can change in response to HRR, we can make that work.

 > > 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.
> 
> I'm not sure I follow this point. Do you mean the draft as-is, or the 
> PR? I don't believe the draft as-is does, and I don't think the PR does 
> anything to the transcript that draft as-is doesn't already do. The 
> transcript behaviors are largely forced by a combination of backwards 
> compatibility for ClientHelloOuter and split mode for ClientHelloInner. 

I refer to this, which I would propose be cut:

> Note: if ClientHelloOuter and ClientHelloInner use different groups for their key shares or differ in some other way, then the HelloRetryRequest may actually be invalid for one or the other ClientHello, in which case a fresh ClientHello MUST be generated, ignoring the instructions in HelloRetryRequest. 

-- https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-6.1.4-4

> I think you may have misunderstood #333. That or I'm misunderstanding 
> your response. Imagine a client-facing server that wants to support HRR 
> statelessly. When that client-facing server accepts ECH and gets an HRR 
> from the backend server to forward, it has no opportunity to inject its 
> own cookie.

Yeah, I missed that distinction.  Let's not support that.  If the client-facing server wants to forward AND use the cookie to route the second ClientHello without maintaining state, let it coordinate with the hidden server.
 
> In terms of sticking out, Ben Schwartz also pointed out another issue 
> with the current situation. It's not just that, where HelloRetryRequest 
> occurs naturally, this quirk reveals GREASE. A forged HelloRetryRequest 
> also reveals GREASE. This PR resolves this by authenticating the ECH 
> acceptance signal in HelloRetryRequest.

Yeah, that leaks that grease happened.  We can thank those who were overzealous in their interpretation of the rules in RFC 8446.  Either way, this style of attack doesn't really bother me that much as it is very obvious and requires active interception.
  
> I'd be very interested to understand the architectural constraints 
> here. This didn't seem likely to be particularly challenging to 
> implement, but I only know our own stack and certainly could have 
> mispredicted.

As I said in the meeting.  HRR only has limited battle testing in practice, this would be even less tested, but far more complex.  Anything we can do to limit complexity, even at the cost of more complex analysis, is worth doing in my opinion.  There is only one analysis we need to do for the specification, but (hopefully) multiple implementations.