Re: [DNSOP] [ I-D Action: draft-rescorla-tls-esni-00.txt]

Kazuho Oku <> Thu, 19 July 2018 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B200130DC6; Thu, 19 Jul 2018 12:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, 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 gXkcre5UOaRO; Thu, 19 Jul 2018 12:04:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E032D130F50; Thu, 19 Jul 2018 12:04:30 -0700 (PDT)
Received: by with SMTP id y200-v6so178729lfd.7; Thu, 19 Jul 2018 12:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O/V9lCHiDSJtRkq/vqjAHWyoyuR2DfqaBEYyH9whTQI=; b=cKWA9GTv/jSw33Lni6WoAb3Rud2MMSlJCitI5Fst1DvGepLSamTjhmQ+SiGnOFHxEk J2sV5gHtvi3QNuXoKzsRCnOhbqZ3yXJsk10OZWjaY3GzYWGAwmJ+oehn2c5KUPqXYZ2x yLGYWwC4yLBFyotvmBGI33NVHlCx0qeknt6fBc4P+L/7ew8x+uC9xXB6pka+SzyR2YWT DuoMa7J8Av8jW/gEPsRwoi64e8rHDiNsLjv3fcYEbDAW4J6LGbFohmJIhl2ciGcIZttD 4sVOaV29XzQ5UoKoQRK+15wW+RVrZfYCdJ9L9zdUmQbMNLfX1lWxqERWNd0VHcC8gNXF Y91w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O/V9lCHiDSJtRkq/vqjAHWyoyuR2DfqaBEYyH9whTQI=; b=MZDH5l2LZDJb2Y7gJAosN3v13VI5SNyZEqAqorAmRoCSCPK9cZHquBkZywJenzK6C9 mg7hObTNGP3ufE7ShmBdJvRD5nI4R2isRve1SN6CLdjKPqY2ePzmEPjE66NPmBjuix2f zYW6zNmuXFuuyZnEuCMUY6R901jsXuF4YO454UVfA5uRWi+v9dMt2IuVJjbwaZtV5rd1 EwyHu8qjvu7bXmqQ1JZgm/HVteLXy92AGSgaUzrFop8mb02z4QowQv43fs3dohVqSivF HPn2diPknWBIfG/J0XPwgQwJwTRuGFuOKvmFfMPEQB01eXzAI6EBFrXFI3KzMea2LdFd vQsg==
X-Gm-Message-State: AOUpUlE62UigWjhRRuvZbQ/QnXN/B0HgWa8IrvUp5xyhOf1maj+q/AUa js6TNTrTO23ph53t845sDdlgyf8C1YBG9c3W/AM=
X-Google-Smtp-Source: AAOMgpflGmnN/CII6BJ1c1nUgFM3yWDCR6FC+AGahJMji8nLrOWZYepMzFAmWgQzpRv95eRwHeYlmAF7nCE9Yq9us08=
X-Received: by 2002:a19:d44a:: with SMTP id l71-v6mr7215833lfg.28.1532027069109; Thu, 19 Jul 2018 12:04:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 12:04:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Kazuho Oku <>
Date: Thu, 19 Jul 2018 15:04:28 -0400
Message-ID: <>
To: Jan Včelák <>
Cc: Patrick McManus <>,,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] [ I-D Action: draft-rescorla-tls-esni-00.txt]
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jul 2018 19:04:54 -0000

2018-07-19 14:48 GMT-04:00 Jan Včelák <>:
> 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 and wildcard certificate
> * I want to run a couple of services on the subdomains of
> and I want to use ESNI. If a TLS client want's to connect
> for instance to, it will resolve
> A/AAAA record to get server IP and 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 Another annoying thing is that
> existence of TXT record will prevent expansion
> of * A/AAAA for The solution would be to
> request new DNS RR type for ESNI which could be used with
> * DNS name.

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. 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.

* IN A    # IP address provided by CDN
* 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

> Jan
> On Thu, Jul 19, 2018 at 2:27 PM Patrick McManus <> 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.
>> On Thu, Jul 19, 2018 at 1:53 PM, Tim Wicinski <> wrote:
>>> 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.
>>> On Thu, Jul 19, 2018 at 1:47 PM, Patrick McManus <> wrote:
>>>> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák <> wrote:
>>>>> 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.
>>>> 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)
>>>> _______________________________________________
>>>> DNSOP mailing list

Kazuho Oku