Re: [TLS] ESNI and Multi-CDN

Ben Schwartz <> Tue, 18 December 2018 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7431E128D0C for <>; Tue, 18 Dec 2018 12:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 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, URIBL_BLOCKED=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 vHlCSmIoA3l3 for <>; Tue, 18 Dec 2018 12:10:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED80212D84D for <>; Tue, 18 Dec 2018 12:10:05 -0800 (PST)
Received: by with SMTP id v10so13729422ios.13 for <>; Tue, 18 Dec 2018 12:10:05 -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=VLFq4aJRq1rp1MEOkp64xmRwwpfF3N/ZkL3ypvfX1+A=; b=o8qiX5iaAd3uRVb8uvERY7OwHwVLAHkS1cC3Q3s9dGJDdmtvmKLZWjeYqQr6ZlWNhQ vrxvmHhHehzt0HIi7XgzKQAVQ+kaauDpmThy74y6PCuwgz/dBqAbKzBi3OgKhtaQ45Zf dQ8t7M6UpIBFZry4ZC4FZE6ncFfN42uJH7e6Wi/xQLkZ1J9FkhwIO04AaG58vTYljznl vgeepbfxkGd8tYmItO7GlF3mvEG0tD97Pk2D7Y/TannnaevaPuSA7Q05aUni66dzhY2E trFE36qBp/xP7IqV3pIrpNOFVyCP9Rk7oLVupDS/Edxxhj1jhTyJLWpGPaFUdHYz1xtT AqXQ==
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=VLFq4aJRq1rp1MEOkp64xmRwwpfF3N/ZkL3ypvfX1+A=; b=KMbZVHBSoszPy+8MoenUNriU9sgGq/EHf/s6X+Bi/ItgeX6/yO77AW33M4qOd38aHy dcBi0QBoXJNzgNp/YGqI6j57zRFlm0FO5XnK1Ud3gg0pQle7STfilBl/eMfnqFJfGUoj 8V5hTHN0G+xT3JvzcNGgGCtmjBm6qGfMurHbYjs/B/7z6koqt3uRkvW861ofFp5/56un ViNoPWwfXEcbRy/8eQ/+yz4aCKT8U4LcsGejKxx4JGVfWqL1f1Gm5c3kcVut30WuPuGo prCXDQSYi5nG2Hct/MhTBk67XByP8dLN0AlTKF2r+ODRvDk85bXaM7fnLzR83TjuvfMX NCRg==
X-Gm-Message-State: AA+aEWZA7E0Szl7nYJjp43vKsNJQBzcNLXAL7VDm3vhk33qZIpXXGQ9J Qlq5OqKfNbo78PvyibxgqPf1EOx/LmJEwWvr/FfYwQ==
X-Google-Smtp-Source: AFSGD/U5jl2kVTT2lmjruxvg5GtzfcV5C6wHIj1ydA0O3ENXg9jo12sOL6Uc40OBrUl2d5WEtsp5HHfqGBBySD8p4Zk=
X-Received: by 2002:a5d:8ac6:: with SMTP id e6mr14296981iot.235.1545163804952; Tue, 18 Dec 2018 12:10:04 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 18 Dec 2018 15:09:52 -0500
Message-ID: <>
To: "Salz, Rich" <>
Cc: "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000bed126057d517b88"
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: Tue, 18 Dec 2018 20:10:08 -0000

On Tue, Dec 18, 2018 at 2:56 PM Salz, Rich <> wrote:

>    - I'd like to propose a solution to the ESNI + Multi-CDN problem
>    (which has been discussed a lot on this list already).  My suggestion is
>    that we define the ESNI DNS record format as optionally including "stapled"
>    A/AAAA records.
> As in a multiple response?  That might be interesting, but it allows an
> adversary to just strip those responses, right?

I don't think I mean "multiple response" in the DNS sense.  What I mean by
"stapling" is "the ESNI RRTYPE has a defined format that can convey both
the ESNIKeys structure and some IP addresses".  This is all RFC
3597-compliant, and is a unified opaque blob to DNSSEC.

> > This kind of address stapling would only be required of CDN operators
> who want to support multi-CDN deployments.
> Or anyone who maintains DNS records for a site that wants multi-CDN.  Many
> of our customers, for example, maintain their own DNS.  It’d say its common
> because they want switch quickly (very short TTL).  Yes, this usually is
> okay because the initial redirection is done via CNAME, but it is worth
> calling out that explicitly.

OK, to be precise, the stapling would be required of multi-CDN customers
_if_ they do not use CNAME, and instead maintain the various CDNs' A/AAAA
records in their own zone.  As I think you are noting, this is unusual;
most multi-CDN customers use CNAME, which (in this design) means that they
do not have to think about ESNI at all.

>                 /r$