Re: [TLS] Alternative ESNI?

Kathleen Moriarty <> Wed, 19 December 2018 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4F5A124BE5 for <>; Wed, 19 Dec 2018 07:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 M6tj-3e67zk7 for <>; Wed, 19 Dec 2018 07:04:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CE5E124BF6 for <>; Wed, 19 Dec 2018 07:04:25 -0800 (PST)
Received: by with SMTP id i7so22494651qtj.10 for <>; Wed, 19 Dec 2018 07:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cETb6OkoO/lv+ne31S4p1LgnrMdpnib4m5hhNJZbQBg=; b=i4mAHXQGwv7s5L2F/5OFa2r8fyIEqvLHhS90n8JtWL8nEBDJDmA7+xHF5iNO8X2gh5 ordttCV6ePAm22e6pgRxuhkPdRhr7w4tA+ruALe9aKluYY8chZ9PO+feOW4X79ce3Gai NpW9CeNTSo1gPhtgktVWq+8UaZRaF2D+YlPbFn8x2v+GBGzFZ8NhPfd2T1N477/qSjT7 HY1gd196P2A/duy+d3PcNPy0khfNQYzuBRRce5zKaRtDCzqhiiAhqV6N1e1ifKzdvNDv 0C/3+tXiUitJDc+kA1VJ1GRUaH3bKWl89OMFYLPUg6PSarlFqq+aWUIidDJZ2/QLRQhk XWLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cETb6OkoO/lv+ne31S4p1LgnrMdpnib4m5hhNJZbQBg=; b=E3uwBEZhRMcDK8Zmr0ip6V99xF0ZN1JVWeHXd5cDoiJH62/gvviWFOAGTI/SZh2e9C ITeDpvGOsbqZoGoCiGUgXu9UdG7EAL+2FBB8pQD7Jzt/AAjtptGN7c4t9r469Kc1F9/m b6oc4mTwgu4Tkn1gHIAk34qPk0LuxHRLCiWeb8CeaIX4sJuPVyPRLnYoo/fwtxKZv5qG Jj1Dwe+E06Mf9vcYYq8sdJR4HWfx417ylSJR2QN2iKoLZjyut1c7YfGjlLcCQECprm77 gMqCwenH5TlLNY7UQzuCAbUfXeUWjTU05Lugr/kaDED+k5JKvf+OndZrkKguw1kCvlYy oLUQ==
X-Gm-Message-State: AA+aEWZAnlg1KuZHHc1zzehobUXX9URWAYYX5iL3JIuOmet8RhdRSjuj YwJxLXrnfHJQVmbwGqOGc3rzglI6
X-Google-Smtp-Source: AFSGD/Ula1/59Q+SKus1qJdNvxU/6BCmS4vR/8YNI+DNaGX+OX/SzuPpvDR/KXBrxMz6ziB3Qi1Brg==
X-Received: by 2002:ac8:dc5:: with SMTP id t5mr15232603qti.80.1545231864266; Wed, 19 Dec 2018 07:04:24 -0800 (PST)
Received: from ?IPv6:2600:380:bc6c:411e:2091:139b:3d46:e334? ([2600:380:bc6c:411e:2091:139b:3d46:e334]) by with ESMTPSA id q5sm2697965qtq.20.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Dec 2018 07:04:23 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-A0E239C3-24BB-45B9-AFB3-AE163971F142"
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <>
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <>
Date: Wed, 19 Dec 2018 10:04:22 -0500
Cc: Paul Wouters <>, "<>" <>
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <20181215025346.GJ15561@localhost> <> <> <> <> <>
To: Eric Rescorla <>
Archived-At: <>
Subject: Re: [TLS] Alternative ESNI?
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: Wed, 19 Dec 2018 15:04:29 -0000

Hey EKR,

Sent from my mobile device

> On Dec 18, 2018, at 4:48 PM, Eric Rescorla <> wrote:
>> On Tue, Dec 18, 2018 at 10:54 AM Kathleen Moriarty <> wrote:
>> Just a clarifying question inline
>>> On Sun, Dec 16, 2018 at 3:30 PM Eric Rescorla <> wrote:
>>>> On Sun, Dec 16, 2018 at 11:45 AM Paul Wouters <> wrote:
>>>> On Fri, 14 Dec 2018, Eric Rescorla wrote:
>>>> > However, in a large number of cases (e.g., an attacker on your local network,
>>>> > there are non-DNSSEC ways of obtaining this property, such as using DoH.
>>>> Data origin authenticity is not the same as transport security.
>>> Yes, I'm quite aware of this fact.
>>>> DoH offers no guarantee that the non-dnssec protected information you
>>>> received is not modified.
>>> As with all things security, it depends on your threat model. If the attacker you
>>> are concerned with is between you and the DNS server, then in fact it does
>>> provide protection.
>>>> Unfortunately, I keep needing to say this on various IETF lists. The
>>>> move towards "blindly trusting DNS over HTTPS/TLS" servers is misguided
>>>> and just moving the goal post.
>>> I don't think this is a very accurate characterization of the situation. At present,
>>> the vast majority of DNS information is not DNSSEC protected [0], and yet we
>>> have to rely on it. If there's a "blindly trusting" in this discussion, it's that. DNS
>>> over HTTPS is designed to improve the situation, though of course it's not
>>> a panacea.
>>> However in *this* case, it actually covers a pretty large fraction of the threat
>>> model, because (1) many attackers are close to the user and (2) if the attacker
>>> controls your DNS server, then they learn which site you are going to in
>>> any case even before you send SNI.
>> This is written as a pretty broad statement.  Did you intend to say that the attackers for this threat vector are close to the user or many attackers?
> I'm not sure I understand the question you are asking. A lot of the threats 

It’s a broad statement.  If I were to give that acting in a CISO role, it would sound like FUD and I either wouldn’t get very far or wouldn’t get anywhere towards goals the next time around.  Crisping it up to the exact threat, point of risk, quantifying, and prioritizing would help.

I’m hearing from concerned people in the threat detection/response side on this (eSNI) who are not willing to speak up.  This point is also where they sit on a network , typically one they manage and users consent to monitoring in their employment agreement.  They are watching for attackers, including nation-state threat actors.  

When ‘many’ attackers are listed, it sounds ominous.  However, if it were quantified and the exact threat were listed, then judgement calls could be made.  Maybe the threats you are referring to are far worse than nation state supply chain attacks or are ones that TLS as a WG prioritizes.  It would be good to either leave out generic statements or to list something more specific (or a list or point back to the draft that covers this topic).

It’s likely that incident responders will just need to adapt, but keeping a prioritized list of threats and point of defense could be helpful to many.

>> Asking as this could sway opinions and the current solution is well suited to CDNs, not necessarily others.
> Yes, the current solution is generally designed to fit into CDN-like scenarios. However, ESNI is generally not that useful unless you have a lot of origins on the same domain (otherwise the IP address itself reveals your destination), and there are a limited number of scenarios of this type (CDNs, hosting providers, application servers, etc.)
>>> [0] provides an overview
>> This is probably a bit better as a reference as it appears to be kept current:
> Thanks.
>> and includes links to others providing statistics for reference as well.  The validation statistics look a bit better in the following study:
>> where worldwide, they say 16% DNSSEC validates.
> I believe this is measuring something different, which is the fraction of the Internet which is covered by validating resolvers. However, that doesn't reflect end-to-end validation, but (typically) recursive resolver validation, which is a rather different matter. To my knowledge, no generic browser client does DNSSEC validation, for the reason that when people have looked at it it created unaceptable failure rates.
> -Ekr