Re: [TLS] ESNI interoperability questions

Eric Rescorla <> Mon, 25 November 2019 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94F6D120A2B for <>; Mon, 25 Nov 2019 09:12:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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] 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 4KMRgjiY1t32 for <>; Mon, 25 Nov 2019 09:12:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4DDE1209C0 for <>; Mon, 25 Nov 2019 09:12:19 -0800 (PST)
Received: by with SMTP id j6so7776538lja.2 for <>; Mon, 25 Nov 2019 09:12:19 -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=m1soUZ4gZ+sebYkx+IcFAXSmggkjqmyCc9k70ZFy8aI=; b=yzgq8y5aSE6ovAVmiI09IjJmKsMiNl52uHOEi0bAMDELTlNXe8x+8KMnqQt6665I5F VDN9OJNKWVRqIEayqNKDUoNRd+nXbfp+ef3eGzo+ESaau4XOmIgzGy5XS7T1spDs16Fp CjdON7tDQvXmDnTOFChTXo8gDAWceGq7N1ZvjLh8Y83ec8YHM7/eZtVoWDXJMB3Zwkm0 FPiJfoAsnDuP9N5J6K16swYv6sAYa/kZc4KXPcQL3eR+km7XPUmhcocArtfy/DwJFoEE 3WlnOkpg0wUBnAop6Lz2z8TPQWFjfHP1+WPnZL1U8lgeb5MU5TcNcY5MwdnM70A8vaAV gBMQ==
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=m1soUZ4gZ+sebYkx+IcFAXSmggkjqmyCc9k70ZFy8aI=; b=rKwEPGqwibx8zRa2UCFeGAGKmQmhDJLGNZwF8w+5ykD0ERBRcA7IUjq2v9EaW7SEW8 GVFII8Yi6CkAbR3FvvXWnBujW3ux7eKZir7pAcCrX0bjUsRC5XnxVcrQ515Lq3UmF2N2 X7Lj/IQLoD1tFz2xTuc/BfgDmtwHeIJTLhfSC2HL4XOv/q65blBgbH4LVoO2Xg0pIxYI UTqwwogbJv/P/J1PdJ5bROLJMV9JEdmy0P11ZCXk/EFJO5o+eetrDvMMFIoUrNRCI39l 4zWf2KAE5LA/NZ+3Vx7E86hViSycgQZyQCndm5ae6jZhH8CodH9IPocScijL/wfAMETZ s9XQ==
X-Gm-Message-State: APjAAAU2lvWlKwJfXVXhT8j2iJ/ZyqP0p/KQg5C8a4iNVlUTjy7Oz2GN Nh/2nDXqDPRiUsRIGj5SSFpdfnqWUkJUfO+9oLDjMw==
X-Google-Smtp-Source: APXvYqzeF+FAVotNBEDiM2cHLrTzUS9Xs98E4wG4zZz3lTriLO28OJs3KowEyPv1NkYqUx2TW7znBHsHKQlCRujD8SQ=
X-Received: by 2002:a2e:84d0:: with SMTP id q16mr11897820ljh.48.1574701937996; Mon, 25 Nov 2019 09:12:17 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 25 Nov 2019 09:11:41 -0800
Message-ID: <>
To: Rob Sayre <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000a446fe05982edda9"
Archived-At: <>
Subject: Re: [TLS] ESNI interoperability questions
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: Mon, 25 Nov 2019 17:12:27 -0000

On Sun, Nov 24, 2019 at 10:46 PM Rob Sayre <> wrote:

> Hi,
> This client now interoperates with Cloudflare and the
> copy of OpenSSL. It's tri-licensed under the Apache 2, MIT, and ISC
> licenses. It won't be merged until draft-06 is out, at a minimum.
> I found some things confusing in the draft:
> 1) The draft uses field names that carry a lot of weight, but they're not
> always explained in prose.
> 2) I think the draft could benefit from a more procedural description of
> the steps required, like one might read in a WHATWG draft. This preference
> could just be what I'm used to, though.

This isn't really IETF style, nor do I think it's clearer.

3) It's not clear what to do if the server doesn't consult the (E)SNI at
> all. For example, Cloudflare doesn't seem to check things for big clients
> like, which presumably have a dedicated IP. In newer PRs and
> proposals, should a bogus encrypted SNI from the client trigger a retry
> request even if the server doesn't need the SNI?

The handling of SNI is defined in 6066. This document just inherits that.

4) The draft seems to require more precise explanation around the key
> exchange, since it uses some functions from the TLS 1.3 key schedule in a
> novel way. I saw weird names and patterns in both rustls and NSS. For
> example, in rustls, the secret input "Z" ended up being named
> "premaster_secret". It works, but there's a semantic mismatch.

This seems like an implementation matter, especially as the term
premaster_secret doesn't appear in 8446 at all.


> thanks,
> Rob
> [0] Example:
> On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre <> wrote:
>> Hi,
>> I think I have a working ESNI client, but I'm encountering a strange
>> error testing with Cloudflare.
>> I initially tested with "", but found this was a bad idea,
>> because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI
>> triggered no errors..
>> When my client sends an ESNI to a Cloudfront-fronted domain, I get a
>> handshake_failure error (40). According to the -02 draft, this should only
>> happen if the server fails to negotiate TLS 1.3. I've got my client
>> configured for TLS 1.3 only, so this shouldn't be an issue. When I add an
>> unencrypted SNI to an otherwise identical ClientHello, everything works
>> over TLS 1.3. If there are problems with my ESNI encryption, I should see
>> other errors. Things like "illegal_parameter" or "decrypt_error", right?
>> In Wireshark, I can at least see that my encrypted_server_name extension
>> matches Firefox's cipher and key share entries, and the lengths of
>> record_digest and encrypted_sni are the same. Firefox does send some
>> extensions I don't, like ALPN. Does the absence of unencrypted SNI imply
>> the presence of other extensions?
>> I also wondered about extension order. Since the ClientHello.key_share is
>> part of the ESNI calculation, does it need to appear first in the
>> extensions list?
>> thanks,
>> Rob
> _______________________________________________
> TLS mailing list