Subject: [DNSOP] [[email-masked]: I-D Action: draft-rescorla-tls-esni-00.txt]

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 7 Jul 2018 21:19:00 +0200

I think that ESNI is a nice and simple idea to solve the privacy
problems of the current TLS SNI. I forward the draft here because it
uses DNS to publish keys, under a underscore prefix.

Subject: I-D Action: draft-rescorla-tls-esni-00.txt
From: [email-masked]
To: <[email-masked]>
Date: Mon, 02 Jul 2018 16:30:21 -0700
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Encrypted Server Name Indication for TLS 1.3
        Authors         : Eric Rescorla
                          Kazuho Oku
                          Nick Sullivan
                          Christopher A. Wood
	Filename        : draft-rescorla-tls-esni-00.txt
	Pages           : 19
	Date            : 2018-07-02

Abstract:
   This document defines a simple mechanism for encrypting the Server
   Name Indication for TLS 1.3.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-rescorla-tls-esni-00
https://datatracker.ietf.org/doc/html/draft-rescorla-tls-esni-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Jan Včelák <[email-masked]>
Date: Thu, 19 Jul 2018 13:36:19 -0400

Hey,

I just scanned the draft and focused mainly on the DNS bits. The
described method for publishing encryption keys for SNI in DNS won't
allow use of wildcard domain names.

Relevant text in the draft:

   The name of each TXT record MUST match the name composed of _esni and
   the query domain name.  That is, if a client queries example.com, the
   ESNI TXT Resource Record might be:

   _esni.example.com. 60S IN TXT "..." "..."

The reason is that _esni.*.example.com. doesn't work as a wildcard. If
you want wildcards to work, new dedicated DNS record type will be
needed. I think it should be fairly easy to get a new type allocated
as this doesn't require special DNS processing.

Cheers,

Jan

On Sat, Jul 7, 2018 at 3:19 PM Stephane Bortzmeyer <[email-masked]> wrote:
> ---------- Forwarded message ----------
> Cc:
> Bcc:
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Patrick McManus <[email-masked]>
Date: Thu, 19 Jul 2018 13:47:19 -0400

> allow use of wildcard domain names.
Thanks!

I believe the draft is OK on this point because wildcards aren't needed.
While certificates can be valid for wildcard domains, the SNI is always a
specific hostname (and the plaintext hostname informs the DNS question)

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 19 Jul 2018 13:53:27 -0400

Patrick

Can I go and order a SSL Cert with a standard name and a wildcard name for
SNI?  We do that now.

So, I think Jan is onto something.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 19 Jul 2018 14:27:09 -0400

the tls server side (aka the cert side) can definitely use a wildcard (or a
list of explicit names, or a mix of both!) But that's the SNI consumer. The
draft is about the SNI producer which does not use wildcards.

e.g. the ESNI work is about what is put in the TLS client handshake
(historically the SNI and according this draft a new extension carrying the
encrypted SNI) - and that is always an explicit name. And that's also the
subject of the DNS query in order to obtain the keys. The DNS query and SNI
leak similar amounts of information (although perhaps to different
parties), so an encrypted DoT or DoH is an important part of the system.

---

From: Jan Včelák <[email-masked]>
Date: Thu, 19 Jul 2018 14:48:06 -0400

Patrick, I believe my understanding of the SNI consumer side is the
same. I'm talking about inability to use DNS wildcard on SNI producer
side:

Let's say I get domain example.com and wildcard certificate
*.example.com. I want to run a couple of services on the subdomains of
example.com and I want to use ESNI. If a TLS client want's to connect
for instance to www.example.com, it will resolve www.example.com
A/AAAA record to get server IP and _esni.www.example.com TXT to get
the key to encrypt SNI. Is that right or did I miss something about
your draft?

If the above true, then my objection is that I cannot use DNS wildcard
for _esni record and I will have to create explicit one for each
subdomain (service) on example.com. Another annoying thing is that
existence of _esni.www.example.com TXT record will prevent expansion
of *.example.com A/AAAA for www.example.com. The solution would be to
request new DNS RR type for ESNI which could be used with
*.example.com DNS name.

Jan
On Thu, Jul 19, 2018 at 2:27 PM Patrick McManus <[email-masked]> wrote:
>
> the tls server side (aka the cert side) can definitely use a wildcard (or a list of explicit names, or a mix of both!) But that's the SNI consumer. The draft is about the SNI producer which does not use wildcards.
>
> e.g. the ESNI work is about what is put in the TLS client handshake (historically the SNI and according this draft a new extension carrying the encrypted SNI) - and that is always an explicit name. And that's also the subject of the DNS query in order to obtain the keys. The DNS query and SNI leak similar amounts of information (although perhaps to different parties), so an encrypted DoT or DoH is an important part of the system.
>
>
>> Can I go and order a SSL Cert with a standard name and a wildcard name for SNI?  We do that now.
>>
>> On Thu, Jul 19, 2018 at 1:47 PM, Patrick McManus <[email-masked]> wrote:
>>>
>>>
>>> I believe the draft is OK on this point because wildcards aren't needed. While certificates can be valid for wildcard domains, the SNI is always a specific hostname (and the plaintext hostname informs the DNS question)
>>>
>>>
>>>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Jul 2018 15:04:28 -0400

> request new DNS RR type for ESNI which could be used with

I agree that the issue exists. Thank you for pointing that out.

I can see that using a dedicated type resolves the issue for the case
where the DNS and TLS servers are operated by the same entity.
However, that would not solve the issue if the servers are operated by
different entities. Do you have any suggestions on how we can support
that case as well?

Background: In ESNI, we would like to support two types of
deployments: 1) DNS and TLS servers operated by same entity, 2) DNS
and TLS server operated by separate entities.

The latter case is actually common; it is often the case for a website
to select different service providers for DNS and CDN. In such case,
we would like to use CNAME to delegate the ESNIKeys entry from the DNS
of the website to that of the CDN (example show below). Otherwise,
there is a risk of the key (which needs to be rotated) getting out of
sync.

_esni.example.com. IN CNAME 3600 _esni.cdn.example.

However, this pattern does not work for wildcards, because CNAME is
not type-specific. We would want to do something like below, but that
is not possible.

*.example.com IN A 192.0.2.1    # IP address provided by CDN
*.example.com IN CNAME _esni.cdn.example. # delegate ESNI records only

My understanding is that ANAME is coming, but that is for address
records only. It cannot be used to delegate a specific type that you
choose.

-- 
Kazuho Oku

---

From: Patrick McManus <[email-masked]>
Date: Thu, 19 Jul 2018 15:07:25 -0400

Hi Jan,

> *.example.com. I want to run a couple of services on the subdomains of

the esni keys are completely independent of the associated certificates.
Indeed it is anticipated that the same set of esni keys would cover many
different parties and certificates that only share a TLS termination point
in common. (i.e. the esni keys don't encrypt or authenticate https, they
just encrypt the SNI field). so for clarity we should probably move on from
certificate properties.

nonetheless, it is indeed the point of ESNI that the same TXT (or perhaps
ESNI RR-type) content applies to multiple domains - that's what forms the
anonymity pool.

> the key to encrypt SNI. Is that right or did I miss something about
sounds right

> request new DNS RR type for ESNI which could be used with
got it (and as I hinted above, the RRTYPE is an open issue in the bug
tracker - I think there's significant support for making the change though
this is the first I've heard this argument, so I'll add it to the list.
thanks).

Am I correct in saying that what you're getting at is not so much a wire
issue as a convention among configuration and implementations? i.e.
wildcards are synthesized - they aren't actually sent as responses that
clients use in some kind of short-cut kind of way?

Thanks for the help.

> > the tls server side (aka the cert side) can definitely use a wildcard
> (or a list of explicit names, or a mix of both!) But that's the SNI
> consumer. The draft is about the SNI producer which does not use wildcards.
> >
> >>> I believe the draft is OK on this point because wildcards aren't
> needed. While certificates can be valid for wildcard domains, the SNI is
> always a specific hostname (and the plaintext hostname informs the DNS
> question)
> >>>
> >>>
> >>>

---

From: Patrick McManus <[email-masked]>
Date: Thu, 19 Jul 2018 15:36:09 -0400

> clients use in some kind of short-cut kind of way?
[replying to myself] I see now that the wildcards are part of things like
axfr which form an open definition for interoperability.. so they are a
wire protocol element of a sort. Thanks!

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Jul 2018 15:37:17 -0400

> clients use in some kind of short-cut kind of way?

That's correct - wildcards are expanded on the DNS server, not by the
client.

FWIW the same issue appears to arise with the current specification for
carrying the ALTSVC information as a DNS RR, again because of its use of
underscore prefix labels.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Jul 2018 15:39:13 -0400

On 19/07/2018 15:36, Patrick McManus wrote:

> [replying to myself] I see now that the wildcards are part of things
> like axfr which form an open definition for interoperability.. so they
> are a wire protocol element of a sort. Thanks!

Kind of.

Wildcards are carried in AXFR so that primary and secondary name servers
both know to synthesise the required records.

It is technically possible to explicitly ask for `*.example.com` to test
for the presence of a wildcard, but otherwise the synthesis is done
entirely on the server side and the `*` does *not* usually appear in the
DNS wire protocol.

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 19 Jul 2018 16:06:36 -0400

What Ray Says

Also, I have SSL certs right now (sadly but that's another talk) for
aws-region-y.saas.com,  *.saas.com *.foo.saas.com, *.saasdb.com etc.
and let's say we want a ssl cert of aws-region-y.saas.com with all the
wildcards as SNI names.

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2018 16:56:22 -0400

>allow use of wildcard domain names.

Yes, that is a very well known fact about _prefix names in the DNS.

>   _esni.example.com. 60S IN TXT "..." "..."

do this:

   example.com. 60S IN ESNI 983989D92330EA840...

It can use base64 encoded text but it might as well just put the
ESNIKeys structure literally in the record, represented in the master
file in hex string, like the certificate stored in a TLSA record.

It's harder to deploy a new rrtype than an overloaded TXT record, but
you can't have everything.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Jan Včelák <[email-masked]>
Date: Thu, 19 Jul 2018 17:15:02 -0400

> and TLS server operated by separate entities.

Let me sketch how this could work with custom DNS record type. Let's
call the new type ESNI. This is how the DNS records for CDN and our
example.com domain may look like:

cdn-provider.test. SOA ...
cust.cdn-provider.test. A 192.0.2.100
cust.cdn-provider.test. AAAA 2001:db8::cafe:100
cust.cdn-provider.test. ESNI "..."

example.com. SOA ....
*.example.com. CNAME cust.cdn-provider.test.
jabber.example.com. CNAME somewhere-else.test.
no-esni.example.com. AAAA 2001:db8::beef:100
mail.example.com. A 198.51.100.1
mail.example.com. AAAA 2001:db8::beef:200
mail.example.com. ESNI "..."

I think this configuration should support all the deployments you mentioned:
- mail.example.com is configured explicitly.
- jabber.example.com. configuration is outsourced to some other
provider. We don't know if they provide A, AAAA, or ESNI.
- no-esni.example.com is configured explicitly with no ESNI.
- any other subdomain under example.com is outsourced to
cust.cdn-provider.test which providers A, AAAA, and ESNI

> records only. It cannot be used to delegate a specific type that you

We all wish we had solution for this problem. At the moment, you can
use just CNAME which takes all. If you wanna configure subset of A,
AAAA, ESNI, you have to do that explicitly. Also, you cannot use CNAME
at zone apex (for example.com.).

Jan

---

From: Jan Včelák <[email-masked]>
Date: Thu, 19 Jul 2018 17:20:03 -0400

> you can't have everything.

Just a note that IANA action will be soon (eventually) required to use
underscore label:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2018 17:36:51 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

You already need an IANA action to get a new rrtype.  Neither is terribly 
hard, but an underscore label will be easier.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Jul 2018 12:30:31 -0400

> That's correct - wildcards are expanded on the DNS server, not by the

That's true, but there also some more subtly here -- with DNSSEC, the
server also sends the wildcard label to allow the client to know that this
happened - this doesn't change the above argument, but is worth knowing...

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Jul 2018 21:08:02 -0400

> happened - this doesn't change the above argument, but is worth knowing...

So, I misspoke (or, more truthfully, misremembered!) - it is a bunch more
complicated than that, see
https://tools.ietf.org/html/rfc4592#section-4.7
for what actually happens (and thanks to Ray for calling me on it)
W

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.