Re: [TLS] Solving HRR woes in ECH
Eric Rescorla <ekr@rtfm.com> Fri, 26 March 2021 21:25 UTC
Return-Path: <ekr@rtfm.com>
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 EF2BE3A112E for <tls@ietfa.amsl.com>; Fri, 26 Mar 2021 14:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 eoq2iy3xHZEW for <tls@ietfa.amsl.com>; Fri, 26 Mar 2021 14:25:14 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFC43A10F6 for <tls@ietf.org>; Fri, 26 Mar 2021 14:25:12 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id o10so9664922lfb.9 for <tls@ietf.org>; Fri, 26 Mar 2021 14:25:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OBtJsE04qWegl3V2Xac2/Ck7/A08uk1roTEwTZbv6fA=; b=ZIHpm5V6B2I1rq6E63FxqWKobUWkJH5IhGr8DQ+ZkXPy1AC3DB9H1tolB6nLVSka5C rkf1pnjiUY/RNf9n//qdRCADnx9oHf7OaRuUD4ISFQ5ji0PZ7JE0WVTGszUzU1viv6/G +tekiQW6TpLLrHAOmTgNzAzpYL0zmGdwOOzeadtmx65/pR7703nE2jZugyMQNzaRzL/B 1zqp4ebJWZlvpURdcxyIx048rhPSCFRHRSBsMPSngltAzCHGw8/969Dkv5oAmI99ZkWY V/KJwt+1HojuEoUIDhx/x8mi4kuoUgIIpY4Hd/YB6AepZ4w/aT3AQIj6ljqtJPQNvd7g J5qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OBtJsE04qWegl3V2Xac2/Ck7/A08uk1roTEwTZbv6fA=; b=JsPoCaxvJQPg9aG7mUtem2i+43RS96dD4N/TwsSQKzj365x+eltgr0BB0n2uwpe961 aJjEY4LzGPLHEntKXlYBcXbN7yMhuenOojg8tanBaidJUwF0mu37+HR6J5vDoxpBRrP+ y9M2hs6OGgApBdi2d0ytuwMtyKZyp2+tS260ZjK6p2FYSaAKd80sGhbm7obCZukwHPcs OmqV2BG3495DOu7Nm5HSrv+tuzziRvfDqYVI8tljuxjlX+kJkXS+exV91sixcHg/mm55 bmGPlgarFMimx8gq707QcMSn159F2zgtwaZpyRGdZRP75q3ovySGU8/IyQYBgRIUX0LY a53g==
X-Gm-Message-State: AOAM530CdAufzWueemPxGHrrG8ju5QHRFg2XXFPKL7//WZQoFgumSCTK Ml+ZTRRinFLF4km9fXuUBupa9LaJuW+KqJoqIEEsWWPKaJdDSQ==
X-Google-Smtp-Source: ABdhPJyEFBxeHR3BE0GrwBP/Ea+Dr3fSphQfz5vaUns7XAiLWcZm9Wr7jgBbt34jjps5rzUlcXOpHx6FNptSU1yXQo8=
X-Received: by 2002:ac2:4d9b:: with SMTP id g27mr9348568lfe.113.1616793908916; Fri, 26 Mar 2021 14:25:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAG2Zi20utVzjUnTAWcRSxbhjexhJLvZ9aHT--nn_5jk82MRt=g@mail.gmail.com> <CAFDDyk_0NdYvaXgnUp21DkxTogUJrhN4xwEtnVNTkXvhzKKOGw@mail.gmail.com> <CAHbrMsA4ng7nJj-O+H0uhC6qULsP7jgiFD8gT-S6Lcmfq+k9Ow@mail.gmail.com> <c9df2a3a-dd87-ea30-49cb-c69ea4f2ef20@cs.tcd.ie> <CAG2Zi21YTHDMK_-WMFtYBo2Xnj1Sx-VR1SQeyyc0uwomRO1GUQ@mail.gmail.com>
In-Reply-To: <CAG2Zi21YTHDMK_-WMFtYBo2Xnj1Sx-VR1SQeyyc0uwomRO1GUQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 26 Mar 2021 14:24:33 -0700
Message-ID: <CABcZeBNp3EJ6F_+yCUSU9PbW+WzoVVz=FNx9O=EOuWzJ66pLDQ@mail.gmail.com>
To: Christopher Patton <cpatton=40cloudflare.com@dmarc.ietf.org>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009dc81005be772a5c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7ZXUO3khkoMp36ck8u5xMgN7o5I>
Subject: Re: [TLS] Solving HRR woes in ECH
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: Fri, 26 Mar 2021 21:25:27 -0000
On Fri, Mar 26, 2021 at 9:30 AM Christopher Patton <cpatton= 40cloudflare.com@dmarc.ietf.org> wrote: > I really like this idea, but I don't see it as a solution to ECH's HRR > woes. NIck's idea boils down to providing a recipe for how to construct the > CHOuter, but AFAICT, there's nothing in the TLS or HTTPS-RR specs that > requires the client to follow this recipe. We would still need a way of > reconciling differences in preferences between CHInner and CHOuter. > Note that this might also be of value without ECH. -Ekr > I think we should pursue using HTTPS-RR this way independently of ECH. > It's not just useful for ECH, after all. All connections would benefit from > knowing the server's preferences in advance of the ClientHello. > > Chris P. > > On Fri, Mar 26, 2021 at 8:10 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> > wrote: > >> >> Hiya, >> >> On 26/03/2021 13:44, Ben Schwartz wrote: >> > This seems like a reasonable suggestion to me, so long as the value is >> > purely a "hint", as you seem to be proposing. I would suggest >> structuring >> > it as an ECHConfig extension. This would avoid the need for multiple >> > points of integration between TLS and DNS, support the use of HRR hints >> in >> > other ECH use cases that don't involve DNS, and help to exercise the >> > ECHConfig extension mechanism. >> >> (I'm not stating an opinion on the PR yet but...) If there >> is to be some new data included in SVCB/HTTPS RR values then >> that ought be structured bearing in mind who produces which >> bits of data. An ECHConfig is a binary blob mostly produced >> by the client-facing server, whereas TLS parameters for the >> backend server are not produced at the same place. Including >> the latter as an ECHConfig.extension is not therefore a good >> design IMO. Justifying those (IMO:-) unnecessary ECHConfig >> extensions is also not a goal. >> >> Information about the backend's TLS preferences, if published >> in the DNS, ought be outside the ech value in HTTPS RRs. If >> we wanted to publish information about the client-facing >> server's TLS preferences in the backend's zone file, then >> that could be put into the ECHConfig all right. (It's a pity >> that we didn't split out the ECHConfigs from different >> client-facing servers in SVCB/HTTPS to make all that easier >> isn't it?) >> >> Cheers, >> S. >> >> > >> > On Thu, Mar 25, 2021 at 9:28 PM Nick Sullivan <nick= >> > 40cloudflare.com@dmarc.ietf.org> wrote: >> > >> >> Hi Chris, >> >> >> >> HRR in ECH does seem challenging. This may be tangential to the PR you >> >> linked, but there may be a way to reduce the likelihood of HRR by >> moving >> >> even more of the handshake negotiation into DNS. The HTTPS RR is >> already >> >> used for some types of negotiation (ALPN and ECH key), so why can't it >> be >> >> extended further to advertise to the client what the server is willing >> to >> >> support for cryptographic negotiations? >> >> >> >> For example, the HTTPS record could additionally contain the server's >> >> supported supported_groups and cipher_suites. With this information, a >> >> client could know which key_share extensions a server is likely to >> accept >> >> and adjust its clienthello accordingly. A client who typically sends >> two >> >> key_shares (P256 and x25519) for maximal compatibility could then >> reduce >> >> the size of its client hello (no need to send redundant key_shares) or >> even >> >> prevent an HRR flow altogether in the case that the default key_shares >> or >> >> cipher_suites are not supported by the server. >> >> >> >> This tweak wouldn't remove the need for HRR completely -- it could be >> >> necessary when changing server configuration, for example -- but it >> could >> >> remove the need for HRR in the common case. >> >> >> >> Nick >> >> >> >> On Thu, Mar 25, 2021 at 8:05 PM Christopher Patton <cpatton= >> >> 40cloudflare.com@dmarc.ietf.org> wrote: >> >> >> >>> Hi all, >> >>> >> >>> One of the open issues for ECH is how it interacts with >> HelloRetryRequest >> >>> (HRR). The central difficulty is that a client may advertise different >> >>> preferences for HRR-sensitive parameters in the ClientHelloInner and >> >>> ClientHelloOuter. And because the HRR path has no explicit signal of >> which >> >>> ClientHello was used, the client may not be able to know how to >> respond. >> >>> The following PR solves this problem by adding to HRR an explicit >> signal of >> >>> which ClientHello was used: >> >>> https://github.com/tlswg/draft-ietf-tls-esni/pull/407 >> >>> >> >>> The design was originally proposed by David Benjamin in the issue >> >>> referenced by the PR. Along the way, It also solves a handful of >> other HRR >> >>> issues that have been identified. >> >>> >> >>> One consequence of this particular solution is that real ECH usage >> >>> "sticks out" if the server responds with an HRR. In particular, >> signaling >> >>> which ClientHello was used also signals whether ECH was accepted. >> However, >> >>> the solution is designed to mitigate "don't stick out" attacks that >> attempt >> >>> to trigger the HRR codepath by fiddling with bits on the wire. The >> >>> distinguisher only arises when HRR happens organically. >> >>> >> >>> Feedback is appreciated! >> >>> >> >>> Best, >> >>> Chris P. >> >>> _______________________________________________ >> >>> TLS mailing list >> >>> TLS@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/tls >> >>> >> >> _______________________________________________ >> >> TLS mailing list >> >> TLS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tls >> >> >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Solving HRR woes in ECH Christopher Patton
- Re: [TLS] Solving HRR woes in ECH Nick Sullivan
- Re: [TLS] Solving HRR woes in ECH Carrick Bartle
- Re: [TLS] Solving HRR woes in ECH Ben Schwartz
- Re: [TLS] Solving HRR woes in ECH Stephen Farrell
- Re: [TLS] Solving HRR woes in ECH Christopher Patton
- Re: [TLS] Solving HRR woes in ECH Eric Rescorla
- Re: [TLS] Solving HRR woes in ECH Eric Rescorla
- [TLS] key_share hints in DNS David Benjamin