Re: [TLS] DNS-based Encrypted SNI

Kathleen Moriarty <> Wed, 04 July 2018 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01736130E09 for <>; Wed, 4 Jul 2018 11:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 P9YYHzKiSTNw for <>; Wed, 4 Jul 2018 11:10:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34116129619 for <>; Wed, 4 Jul 2018 11:10:21 -0700 (PDT)
Received: by with SMTP id y31-v6so5152578qty.9 for <>; Wed, 04 Jul 2018 11:10:21 -0700 (PDT)
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=+LFSy2OLnj9fLymDpHmlZJOE6U1EV8u9W6llVccAx/c=; b=ik8zpJ35PjgticloIxUK2XiQAd2jL9bDDtFrlHNEcLi0jfTEDzTEHINeqfRa6iU9fZ wYj5n53Fhu5sK9i2XuHNXqDk7fpC73amS9e+CeIkA3dS6UGs3ZaIl7DBKBfFioN4+uQW WKlFWaPV4jXuz4piiT3V/AbDVKk3cph9j7GnnrqDcTMnELoqcsDwKnk/gwYcrq+vmSxQ dDMBzyAaR0CLJqovI7io86C9zq3JGDPSaG68WQ4w9Cs+vIuY/6pH+5ddWi916Q18FEFj ZeETMd+N+AKdWC5ELZTCqgWA7GZDIPonCFI5IuUE5UilCCm8QvSoIZWLFFF4bOXS5Bq8 4oMA==
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=+LFSy2OLnj9fLymDpHmlZJOE6U1EV8u9W6llVccAx/c=; b=J/KCARDm9K9PbogTjP0DBN1+kbifr+/aVe26G7FuyHcZR2WmAnrFxMmEak1HKNs5Dk cSvCeE16o/NFJCiqJw8PuVy86RNyWxdXgdctf8h70viF/OlzfzTGvviMOyTL++87tO24 /th+SrrGDPOoXH4w/NRuZwbAMuHRnD0RTWIDyw1wwO3zFS9qCLoiCItz1G63MdPImhba 4W3MQOUgM44GrVhPiBAxO3uPY1buef1TsVoCx51I9z7d34Htuz0pesMfex9YEGYgY98A 8h0g7vSRSiuFTjCurlK3WKNapkD580lGSHpy461QvFJHdzJS6U+66POiAoAOFW0GI+t9 eYZA==
X-Gm-Message-State: APt69E3FxtZ6Nz5kjxj1i33fdjF2g6GnkJj2pt++ZicCUCI4Mel79mzO NHki1QA7VUAB99Ek7eVUveY=
X-Google-Smtp-Source: AAOMgpcDjwkZOB1S82I/lygtXIvK92h5YyAMmiiRE4HhxfUldcWXL5fel8xvltcoCAC7V10Iy+pWGQ==
X-Received: by 2002:ac8:38ac:: with SMTP id f41-v6mr2593164qtc.190.1530727820279; Wed, 04 Jul 2018 11:10:20 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id c9-v6sm2791780qtc.34.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 11:10:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <>
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <>
Date: Wed, 04 Jul 2018 14:10:18 -0400
Cc: Eric Rescorla <>, "<>" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Stephen Farrell <>
Archived-At: <>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-Mailman-Version: 2.1.26
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, 04 Jul 2018 18:10:24 -0000

Sent from my mobile device

> On Jul 4, 2018, at 9:01 AM, Stephen Farrell <> wrote:
> Hiya,
>> On 03/07/18 00:39, Eric Rescorla wrote:
>> Hi folks,
>> I just submitted:
> Thanks for writing that up. I think it's an interesting
> addition to the set of potential solutions.
>> This draft describes a DNS-based approach to doing encrypted SNI.
>> Previously, we had thought this wouldn't work because only sites that
>> were particularly vulnerable would do it, and so the use of ESNI marks
>> you out. The idea behind this draft is that there are a lot of sites
>> which are hosted by -- and whose DNS is run by -- a large provider,
>> and that provider can shift many if not all of its sites to ESNI at
>> once, thus removing the "standing out" issue and making a DNS-based
>> approach practical.
> I'm not sure I fully understand how this approach would fit
> with others, nor to what extent it depends on the DNS and
> CDN providers co-operating, but it definitely seems worth
> exploring.
>> I am working on an implementation for NSS/Firefox and I know some
>> others are working on their own implementations, so hopefully we can
>> do some interop in Montreal.
>> This is at a pretty early stage, so comments, questions, defect
>> reports welcome.
> Quick comments after flicking through the draft:
> - I'm not that fussed myself as to whether this uses a TXT
> or new RRTYPE. But if the latter would work, it seems better.
> - I didn't quite get what "all the domains" in 3.2 means. I
> guess if a client uses non-encrypted sni for one of those,
> it should still work, but I'm not clear if supporting esni
> for any domain means that the provider has to decrypt esni
> and then deal with successful decrypted sni values as if
> the client had sent sni in clear. A concern is requiring
> "all the domains" might make it hard to roll this out.
> - I guess some form(s) of key rollover will be needed, ut
> I'm not sure that not_before/not_after is the best way to
> do that.
> - The ESNIKeys structure generally seems a bit complicated,
> it might be better to aim for simplifying that and maybe
> making it more "zonefile friendly" (whether in a TXT RR
> or not).
> - It might be interesting to think about how this'd work
> for e.g. the IETF web site (where is hosted
> locally but is not), and for STARTTLS and
> MX RRs. That's probably ok, but I've not gotten it
> straight in my little head yet:-)
> - Would it make sense to include the innocuous dummy sni
> in the published RR, so that all clients use the same
> one and stand out that bit less?
> - 7.1 probably needs more work - I'm not sure that it's
> that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
> or a client application that knows the ESNIKeys, are most
> likely needed, but there's probably also some work to do
> to analyse the recursive to authoritative interactions to
> get the ESNIKeys even with DPRIVE.
> Lastly, the topic of whether or not to try address this
> problem is something that the WG has debated quite a bit,
> and IIRC the consensus after that debate was to do work
> on this (hence Christian's draft).
> So I don't see any need to debate whether or not to work on
> this is needed, and trying to re-open such a debate seems
> somewhat disruptive to me. It is entirely reasonable to
> consider what, if anything, widespread use of esni or other
> approaches might break though. But going back to all this
> "privacy at any cost" and "we're the enterprises" hyperbole
> is not at all helpful IMO, so I hope we don't have to suffer
> more rounds of that. But maybe that's inevitable with every
> iteration of attempts to improve privacy sadly;-(

I’m also fine with the work going forward, however it was only in March that EKR assured people concerned that they don’t need to worry about SNI being encrypted repeating similar statements previously made to the same effect.  Meantime, he was working on such a solution.  People need warning to prepare for changes, not to be surprised by them after being told not to worry.  They may not have had a chance to think through how they might adapt.


> Cheers,
> S.
>> -Ekr
>> _______________________________________________
>> TLS mailing list
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> TLS mailing list