Re: [TLS] Proposals to address ESNI issues

Rob Sayre <> Tue, 05 November 2019 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13683120025 for <>; Tue, 5 Nov 2019 14:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4T_CGn1TPXfK for <>; Tue, 5 Nov 2019 14:54:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F29F8120018 for <>; Tue, 5 Nov 2019 14:54:32 -0800 (PST)
Received: by with SMTP id r144so24670302iod.8 for <>; Tue, 05 Nov 2019 14:54:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CE+IuNw+7S5CRzWOOQkdYepSycoVvGpr4lyE7EagOIU=; b=R5h7Yv2I6Bymz+EJ9Y+cqct7k3hkFk3NVIhh6lAooil3EzIwF8LAkAYMrjxw5VbunP wHlv15KTK43iD/7oscWMhsb2gENumCpMNOjwZLtr4+J9o8ajU9opibWL5EuQBXJ/3ibo DDG/rJ+rrHskDultQh8VMI/8HGsEl6Z/8rc1oXWf2iTrEC9t4zxWeaE7Qw+lWu+81Y1c uDAcJE1FoXWm6Xj7hlaIHWiyF2Qng5zEPEAfscXRnBkJlR/Aq2JqpaX9FVK3NVQs+8Wx AKLkBch9QtyNgi/9Ru6bD4HbGCoAbtNPEICuozOknXEoOH5Zp36rFxbq3QADKk741o4m TfyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CE+IuNw+7S5CRzWOOQkdYepSycoVvGpr4lyE7EagOIU=; b=X7JhZ7dafh/IQ3ArL8hWJbvcvnDtl1c/SJOAxJpTKkPlRNfY+OYsbhkk9IO9WKZOiZ eVv2ILbdl0l9XgxnW7VY/3XAz5dsE6u05aY2RLL+EE8/qNkhPr3yBCVFr49b1Ngm7b6z v9ohoCuOQdtWljtIuWGydT0ltOzBgl2jzZX7G/6FO+bVvZqg0bdB61+0ZXUqi4hLrc/P oz/paxIlmzDfISp68IVLyiYKLvqPRTSs/3DY72p2csjnVay+GJ7u3qXEtbpDw0gdD6J8 F9m4AWOWkR+brlYQrp1gVvKDypSjB7OkU4ZqOKcNpT/CgZlSTb5WPz0Vk3GmcLMivWbK Ef4Q==
X-Gm-Message-State: APjAAAXsIA10GvGVwAnmDNLKSY42wPcs6FFN/Pfi5sg59rMMYXilAIan Mw2OYat26Yo0CJaIQf+XZUX1fRlUZ4ZsvsWpacA=
X-Google-Smtp-Source: APXvYqwdPdxE99DprSxHldBqdqpfEl8cj6xSXfkRs7Cnp5EhqbVoO6dkiqGpXyNz8Hmg5i92dBut/iew3AcZDjfZAJg=
X-Received: by 2002:a6b:400e:: with SMTP id k14mr6644127ioa.254.1572994472244; Tue, 05 Nov 2019 14:54:32 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Rob Sayre <>
Date: Tue, 5 Nov 2019 14:54:19 -0800
Message-ID: <>
To: Eric Rescorla <>
Cc: Christopher Wood <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c079ad0596a1505d"
Archived-At: <>
Subject: Re: [TLS] Proposals to address ESNI issues
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2019 22:54:35 -0000

On Tue, Nov 5, 2019 at 2:43 PM Eric Rescorla <> wrote:

>> Isn't the HRR attack detailed in that section of the PDF (attachment 0 in
>> Chris's message) contingent on using only the "KeyShareClientHello" as
>> input to the AAD?
> No. In the HRR attack, the ESNI block is provided by the attacker. This is
> laid out in S 2.2.
> " his reveals the basic source of the problem: in order to prevent
> mix-and- match attacks on the client’s key share, the ESNI encryption binds
> in gx. How- ever, if the server uses the SNI from first ClientHello and
> then the key share from the second ClientHello, which is
> attacker-controlled, then the attacker is free to generate their own ESNI
> extension containing a bogus ESNI and nonce. The server correctly verifies
> that these correspond to ga but because these are all supplied by the
> attacker, this check succeeds and the server encrypts the certificate to
> the attacker with a key known to the attacker."
Ok, maybe I have misread this section.  It says: "and then the key share
from the second ClientHello, which is attacker-controlled". Wouldn't
including more of the initial ClientHello in the AAD parameter prevent this?