Re: [TLS] Proposals to address ESNI issues

Eric Rescorla <> Tue, 05 November 2019 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67228120025 for <>; Tue, 5 Nov 2019 14:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 v2fvtF8ZbS30 for <>; Tue, 5 Nov 2019 14:43:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2385D120018 for <>; Tue, 5 Nov 2019 14:43:21 -0800 (PST)
Received: by with SMTP id v8so8134004ljh.5 for <>; Tue, 05 Nov 2019 14:43:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ulZm1c7emA5NbSZ1APsZRbo775lakPWzJifiBUR9zo0=; b=C4kK+c6CAa2OHFYNCvv5tCiF+7X49s8DmhmWz259vtNskRvXitlw8ECyXqL/loKWMN 8n/pzfIr6YEF/eG5Du7HKZMMv/LvWnuWJDzPoK7J3FgKsHvRzXNQi58fV8QjeRFQCMGy ybDeq/FUu0DX4cTQPt5JpdadD4o/0PDKFqlsTxG8C8U4gr3qGtrQ7QAN3w8drQRbdHIv IogkZ6+hLDT23OKcfrS38CTtRAwWZdcKyckoSWBlybnqlIPk6QVuUedjWjuWnaExGYKF Vd0cPoTfGRNVPyrG+65FPBu/BPMdBz7SMppJXJumGRVRettPS+NVNwOFJNkUDaqiVQTj vXIA==
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=ulZm1c7emA5NbSZ1APsZRbo775lakPWzJifiBUR9zo0=; b=Wwo8uCIpcacSBDNCb6BNa95qkJjblOKBjb0xe7gmWZJjX3MhB4UfRqDhu+dpYEbKlh grv9Ggop4PPKWDQxn3lO92TUW9x1if5xI1z6V3TsCqttJAdCY5zmzSefjSx5zcMHwdam WRYcv0qkS6Dc4YSMGq0eFMf3znKi7b1BMVe9pWsmxtUgzw0qDdMjgNi6GUT8h8NbWMxz oORzbio0zx+T7ykLXvhJDR1dBULBbzDXHUW6wqsyXx4Wt2fpL8suoAMgZOdYyOFhUxJR vr8hWqgnuV/cCQ5wHUk6jO9CAqRE5OpROFhcBz7cYxBvgmHPcJDryPS0PD/DzO+2g/cY xoFg==
X-Gm-Message-State: APjAAAUmqz9itTuZ6B274GptnV9sUpv19V7rvurLxoKoeEJ4OtTpUWXZ W4i+x5e+T0hDrH2yZN5S2oHSvwjlx0L3oAQsMUj0cQ==
X-Google-Smtp-Source: APXvYqzO93u6FtzBgrR13EIWMmT7kMO2YUdevzxPit5DxoQjdWomee/6ZLtOFV+g0kIzEV9kCWN1JZNqvZB/EvS4aio=
X-Received: by 2002:a2e:420a:: with SMTP id p10mr25788712lja.16.1572993799347; Tue, 05 Nov 2019 14:43:19 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 5 Nov 2019 14:42:42 -0800
Message-ID: <>
To: Rob Sayre <>
Cc: Christopher Wood <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000a4fedb0596a128fe"
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:43:23 -0000

On Tue, Nov 5, 2019 at 2:31 PM Rob Sayre <> wrote:

> On Tue, Nov 5, 2019 at 2:15 PM Eric Rescorla <> wrote:
>> On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre <> wrote:
>>> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood <>
>>> wrote:
>>>> >
>>>> > The attacks on ESNI security above seem to stem from two problems:
>>>> >
>>>> > 1. The ESNI contents are not fully bound to the ClientHello contents.
>>> This seems right to me. I was surprised that the current ESNI drafts
>>> only require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt
>>> function. Additionally, I've raised the point that even that arrangement
>>> seems to imply that the client's key share message should appear before the
>>> ESNI, or that the server must perform some input buffering.
>>> Perhaps a variation on the "Tunnel CH" idea is in order: require that an
>>> "Encrypted Client Hello" is the last extension in a ClientHello message.
>> This wouldn't change the situation in the tunnel CH, because
>> ClientHelloInner does not depend at all on the outer part of the CH.
> I think my suggestion was that ClientHelloInner should depend on the outer
> part, by requiring that it be the last extension, and using all of the
> previous input in the AAD parameter.

That doesn't exactly work because the PSK extension *also* has to be last.
That's the reasoning for the injection  + PSK approach, which is
effectively this, except without duplicating the CH.

However, in the tunnelling version, you ignore the outer ClientHello when
you use the inner one, and so everything is bound together without
requiring any specific ordering.

> 2. The handshake secrets are not bound to the ESNI contents. If this were
>>>> not the case, servers could not choose attacker-controlled keying material
>>>> yet proceed with victim-controlled parameters (SNIs).
>>> I had a hard time parsing this point. Doesn't the current protocol
>>> require echoing some encrypted content?
>> Yes, but that doesn't affect the HRR splicing attack. This is laid out in
>> S 2.2 of the document Chris forwarded.
> 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."


>> I think the draft might need to address the case where servers ignore the
>>> SNI and ESNI messages.
>> I'm not sure what you mean by "address" this case. The purpose of the
>> nonce checking is to detect when ESNI was not processed.
> I've found that existing clients do not fail when the ESNI is not
> processed. Unfortunately, I discovered this by writing a buggy client. :)


> thanks,
> Rob