[TLS] ECH: Reuse HPKE context across HRR

Christopher Patton <cpatton@cloudflare.com> Tue, 10 November 2020 22:27 UTC

Return-Path: <cpatton@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9E3A118B for <tls@ietfa.amsl.com>; Tue, 10 Nov 2020 14:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=cloudflare.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N3QHhR5SeDJY for <tls@ietfa.amsl.com>; Tue, 10 Nov 2020 14:27:16 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 44B393A1183 for <tls@ietf.org>; Tue, 10 Nov 2020 14:27:16 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id 7so5486733qtp.1 for <tls@ietf.org>; Tue, 10 Nov 2020 14:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=XKsonG+Qw7e5P68HmJaDd3J+GtzeiUaR48+iIRNz+Xk=; b=etdLj+j2aJ0SAsYK956cUmM5PbYpqeF8GgwueT3p0K5mdJl+l95ZEWGNYgyl6DcGaN 6AsX8frxRuPtAATb5o1R+PZRQ/gZW0YgWSetYcsCDEx1qyj1sWnVXv++FAOFuQTIn42D Nl9jAuC7bqHhW0zG0Ba1JPicm9ZHA8Ih5DUMs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XKsonG+Qw7e5P68HmJaDd3J+GtzeiUaR48+iIRNz+Xk=; b=NNPtZCJemVeieFrJwx4FbMRWGPBxjK58WYaWYZXPz+vo2bYqbqtpBaO2UOiJR6CBmA Y3WBkj+cZENiSxU/OEwD9Fb2pwLsknOrH6+jZshsHnzj+kKeZxKSFAVDQ82klD8rpdD3 q1aS2c032pNRvj3HaIXLCoExQtcirqWBQBDqED1gf4zWJ1IhPJqTDc4mYVVrtkInMT7B y7fxYaGbViND9KINnDSQdF/IoDu0Phjc5y0MZNimyUVX6OKLhVlZKTJ5t+8KD7/N5qDo F7O8ejp+APWXLFCLiIvdBohkPuaEdyZNO8qc/Jz3S8Ogfc2lBV3intl8SzbC9mjFkUtJ rq/g==
X-Gm-Message-State: AOAM530F4gmZoCP5aUzeskgWkouoWL43I/P7gXG/REIh9Bw4TTbkFB8R kacm683HXh5nk9POwQeiBGz723W4K0/dSyOwNN7YJeYLa0+M5g==
X-Google-Smtp-Source: ABdhPJwiZTAeqf2NK1kNnysT1AaSADWxldg6zMsIuRe9OrG1QPPFsO6eyFBCt8hP1QT/0mqXTUfltmndn/AjXYSlv9s=
X-Received: by 2002:aed:3383:: with SMTP id v3mr20684654qtd.353.1605047235133; Tue, 10 Nov 2020 14:27:15 -0800 (PST)
MIME-Version: 1.0
From: Christopher Patton <cpatton@cloudflare.com>
Date: Tue, 10 Nov 2020 14:27:04 -0800
Message-ID: <CAG2Zi20JWODfYqNZMZ2bm0F5DbET+i+swMw1L-j5jk28Kk8Myg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004c788505b3c82ed2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PnDhvHZJYL88AOTo5KOvdwdYM7w>
Subject: [TLS] ECH: Reuse HPKE context across HRR
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: Tue, 10 Nov 2020 22:27:18 -0000

Hi list,

In case the server sends a HelloRetryRequest (HRR) the client generates a
fresh ECH extension, including generating a fresh HPKE context and
corresponding encapsulated key. The following PR changes the spec so that
the HPKE context generated for the first ECH extension is reused to compute
the second:

This design has at least two advantages:

   1. Currently the spec requires the HPKE context to export a PSK, which
   in turn is used to generate the second HPKE context. This means that the
   client (resp. the server) has to implement both SetupS() (resp. SetupR())
   and SetupPSKS() (resp. SetupPSKR()). Advancing the HPKE sequence number
   before encrypting the second ClientHelloInner appears to serve the same
   purpose as the PSK (see {{flow-hrr-hijack}}.) The advantage of the new
   design is that the client (resp. the server) doesn't have to implement
   SetupPSKS() (resp. SetupPSKR()).
   2. Instead of two decapsulation operations --- one for the first CH and
   another for the second --- the server does just one decapsulation. Not only
   is this slightly more economical, it avoids edge cases that arise when
   decapsulation is offloaded to an RPC server. This allows us to simplify the
   server-side HRR logic considerably.

We're wondering if anyone can think of any disadvantages to this design.
Feedback on the PR is greatly appreciated!

Chris P.