Re: [TLS] ESNI and Multi-CDN

Ben Schwartz <> Wed, 19 December 2018 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4197130EBB for <>; Wed, 19 Dec 2018 10:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 opB4FtRF9xX0 for <>; Wed, 19 Dec 2018 10:47:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A10CD130EBA for <>; Wed, 19 Dec 2018 10:47:48 -0800 (PST)
Received: by with SMTP id x28so5252521vsh.12 for <>; Wed, 19 Dec 2018 10:47:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IykluxCKuUqBopOqfHrtd88yvZBqhFNuNe+u06YnbYo=; b=ctAr9v+wQRuoQiTdSiSwkHHodLX2cAT/V/JFQkleAl32xbNp7WIZfyY6AnO3TiwX/2 CcnDSi0EAE++RK/5d/LiZG59Bmtyxf66FdRk7wxsn+JGvH6zLnEhjZXOPnkkY8ri5l1C ruuOo8JrfS+LX3mLecYiFF9ewdBXXdT+8XdDRUo4Ul1jKT16O9IWzdgE5/+b6KsNHWTM +lsfa8Bckovtx3YB8v2MIFiWV4+QvmnDhx5WcWPdV6XgKtQEAGbRzxg/HXH/aB4a2Qc3 eiRfmST7rHGrahVW+i/Ojdhf5FYGBrC97sGyFTwblfXU6PaLdf5OTrK9jVvuXz0S8L4Y pGjg==
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=IykluxCKuUqBopOqfHrtd88yvZBqhFNuNe+u06YnbYo=; b=qvHCIH1yMYVJMzTgSe5/P2+OVdXYhpX/Eob3JlFiU6FkQOXliuYVV6AVE8M8AaerXc k/3cCKZ+YHkn0f/py2l37HCkRH6t7gJ5aYZs3yTFaIB6tf9DP4D+GH7M4ScqbqF5YrlB 8WKahGCYzIHN3IqdtscewUcqJq2C38Kae9CoMfrJAhfoBsczdgxqQkWcZkOErI1ikeP0 mIoKFhe+ZGiqSAU1qIbI2Xx5g4qhh++V0t4ij0lafmEARvAe2m0PEBDuWTFK0bFS3SwL lTpfyiX05hKLWvfP68YjsLOGmv/Xn5CJIFg4q+OLwrpWejdqYVX2oLIPjGPpL8JzUFuW AwlA==
X-Gm-Message-State: AA+aEWbRO/WkcQxNlrUMJ6tWRu1JxjwG/b5qivgW1Uj460WSqgFzeA3D TMUh3vvgxfGLHEgu8W8YqfMA2HIq/vqcPrHPX7I6Ig==
X-Google-Smtp-Source: AFSGD/VUANQKISaBkDxLWtKEpSYYTL17qL0XorElbSPbSdwDOumH+6NJsk3xNn+mv9+q+uD7fScw6o9uJMnofk4SpfY=
X-Received: by 2002:a67:4a96:: with SMTP id e22mr10213270vsg.92.1545245267480; Wed, 19 Dec 2018 10:47:47 -0800 (PST)
MIME-Version: 1.0
References: <> <20181218211435.GB592@LK-Perkele-VII> <> <20181218214928.GD592@LK-Perkele-VII> <> <20181219112748.GA6681@LK-Perkele-VII>
In-Reply-To: <20181219112748.GA6681@LK-Perkele-VII>
From: Ben Schwartz <>
Date: Wed, 19 Dec 2018 13:47:35 -0500
Message-ID: <>
To: Ilari Liusvaara <>
Cc: "Salz, Rich" <>, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000493d5f057d64734c"
Archived-At: <>
Subject: Re: [TLS] ESNI and Multi-CDN
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 18:47:52 -0000

On Wed, Dec 19, 2018 at 6:28 AM Ilari Liusvaara <>

> On Tue, Dec 18, 2018 at 10:46:29PM +0000, Salz, Rich wrote:
> > Here is how it usually works.  Not everyone necessarily does it this
> > way, but in our experience almost all of them do.
> >
> > 1. Sites use a CNAME, usually using a host-specific name.
> >
> > 2. Sometimes the CDN owns the DNS entry.
> There is also:
> 3. The site owns the zone apex DNS entry. And since it is zone apex, no
> CNAME can be used (yes, everything falls apart in practice if you do).
> So zone owner inserts a bunch of A/AAAA records pointing at the CDN (or
> worse, CDNs).
> Fixing the above is a perennial topic. Proposals include CNAME-like
> mechanisms scoped to just addresses, and HTTP service discovery
> mechanisms (as most popular things other than HTTP already do service
> discovery).

Agreed.  This proposal is not meant to address the CNAME-at-apex problem,
and does not make that situation better or worse.

> > Having the ESNI RRtype include optional a/quadA records is something
> > we have talked about internally. If so, it should be part of the RRtype
> > definition, of course. We came to the same idea. Of course, we will
> > then have to fight the intent to make this "generic server record"
> > data such as draft-nygren-service-bindings. :)
> The only use for addresses in ESNI records I can come up with is
> scoping keys to practicular addresses.

Yes, that is the multi-CDN ESNI problem that we are trying to solve.  Each
CDN has its own ESNIKeys and its own IP addresses.

> But one could do that by
> including address masks in ESNI records so clients can match ESNI
> keys to addresses without breaking database normalization.

No, this doesn't work.  If the client has a AAAA RRSET and an ESNI RRSET,
and the ESNI RRSET contains a mask that is not compatible with the AAAA
RRSET, then the client can tell that it has the wrong IP addresses, but it
has no way to acquire the right IP addresses.

> And if one is dealing with the third case above, the solutions are
> basically service discovery. And then one presumably would want it to
> be service-specific (as there are other rarer services that also lack
> discovery besides HTTP).
> > DNS is a strange and wondrous beast, like a bear riding a bicycle.
> > We should make sure that DNS folks are heavily involved in this draft.
> Here are some tips:
> - If you have name references, encode those in DNS wire format and
>   preferably put them first, so that recursives can follow them and
>   include records they think are helpful.
> - Do not assume the above happens (but do assume it may happen). Client
>   has to act as a backstop.
> - DNS is 8-bit clean just fine with new types.
> - Records do not need explicit terminators.
> - There can be many records for each type on the same owner.
> - The unit of atomicity is set of records with the same (owner,
>   class, type) combo.
> - The 64kB limit is not just for individual record but whole set of
>   records with (owner, class, type). And to be safe, limit it to 63.5kB
>   minus 12 bytes per record.
> The following are Bad Idea:
> - Using type or class ANY (a.k.a. *).
>   - Type ANY does the wrong thing.
>   - Class ANY does completely nonsensical thing.
> - Defining a new class.
> - Using class other than IN (Internet).
> - If you use labels, using lots of different labels at outermost level.
> - Putting anything into new type that DNS can not treat as a blob.
> - Assuming authoritatives do anything smart.
> - Assuming authoritatives follow any references.
> - Assuming different types are in any way atomic w.r.t. each other.
> - Copying TXT record wire format.
> -Ilari
> _______________________________________________
> TLS mailing list