Re: [TLS] Two Multi-CDN proposals
Eric Rescorla <ekr@rtfm.com> Sat, 02 March 2019 03:19 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3119E1289FA for <tls@ietfa.amsl.com>; Fri, 1 Mar 2019 19:19:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOJT5O_wr2w3 for <tls@ietfa.amsl.com>; Fri, 1 Mar 2019 19:19:48 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7669D126C15 for <tls@ietf.org>; Fri, 1 Mar 2019 19:19:47 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id d14so22143691ljl.9 for <tls@ietf.org>; Fri, 01 Mar 2019 19:19:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7n8tOq/2tIhMRGr6foklQDKRWl6j87h3FjQhBdvfa3M=; b=ERzwVf94oR5eWM2Gss7MZ684fUl+xInl609lfzvnyrh6uH2g/69Cgj6xXVvzGIaSsw b5A9Kj6KDCKWxSddE9x+FsBrE0prG4E4cnvgIFOq1WQ3rhKSjXf+4bH7U1KxKx/X9sje rzKwGq/duGHBeoTGJvSmBm6jZs4ubmx0i9HiPFkjvhVDaak2GGDp70C7qGTOx6S2crAM F7YvvbBmvTIUecxAtfyKsS5S2j448ThpkBlInGx3EFB+1LxC542qauAev5B7GVoseab7 IZQj4z/4F2PRylHWHLr5yaVf0GXUi+hSeYN2SYJ1wn6SgshshCD4BghHL/ybpYdyArcR iE7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7n8tOq/2tIhMRGr6foklQDKRWl6j87h3FjQhBdvfa3M=; b=QkXbRiyn5Qjx8zEOtEv+lK3owZW1fULB6gbUZDGvwqOLFIhNWUFWJYpTE4aFEl1dS+ KKii3YRK4tWrgwhxsiVnEycwnH1AcVfcnxuiAwdPk6Cqe0WXO+enA1tN1dvLx26kd+SN C87wvQAwH3mdoYXigH4+DWya/T/I64IhAV6YkAe1pgkYB1Vjemry3BDqvyIyMiaoJwyC osjQ9xEeWwYPMcNM9rB+CWHGgkCJlT51zu7/Z5LWJUk9gtuDpPIeSSZft6yLSqOSlf2L y3ejB1RdVW87tvNg/ngK6Oes73770/ZMditxHef1msGPR4eOprjSb+PSEWJeVmpqh9dr IDQQ==
X-Gm-Message-State: APjAAAUIi0SHH6lYmy1p2v2/Z6lAFUoyY+RrXoeDhYB0WHRIoWFJ+QIR Qn8OHpSRvG6QonmbZqvDLbTYcrxhOptvFdAW7VMnug==
X-Google-Smtp-Source: APXvYqxu9dqGi5EwyPuroKViggqssJoHJzDNd+3wtBREJob9WxrMP1y4DJtjudNzF1vCOdUagnscrITVuCu04vnG04g=
X-Received: by 2002:a2e:5d59:: with SMTP id r86mr3936096ljb.158.1551496785414; Fri, 01 Mar 2019 19:19:45 -0800 (PST)
MIME-Version: 1.0
References: <CAO8oSX=sPoLo78oX4qEEyeuck7CxM_uAqYPHEsY7BuYqBUaorg@mail.gmail.com> <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <CABcZeBN0mf7VFCKKdg9gH0=tCS7eLZz6M5_WJdaNG7XrJeyESw@mail.gmail.com> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <CABcZeBM61u=DtjQh+NkQF47MLyZS4EyuGBjDnsfjxz-z5kfjoQ@mail.gmail.com> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> <CY4PR22MB09831CBC251393EE334905D4DA760@CY4PR22MB0983.namprd22.prod.outlook.com> <CAO8oSX=2N=_wvf3L=o6ou=zJaSHE4zpgQDK38QO99+ausYmEpQ@mail.gmail.com> <CAFDDyk_57De_xkXQmhfL_GdojMG0j-=RBhoTFReiCHyArobYWQ@mail.gmail.com>
In-Reply-To: <CAFDDyk_57De_xkXQmhfL_GdojMG0j-=RBhoTFReiCHyArobYWQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 01 Mar 2019 19:19:06 -0800
Message-ID: <CABcZeBPgcTyfA3GHkzcrXPO=dnj1Ea+U4fwcg=4mw6BbO-WkSA@mail.gmail.com>
To: Nick Sullivan <nick=40cloudflare.com@dmarc.ietf.org>
Cc: Christopher Wood <christopherwood07@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c3e6b3058313fe06"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fAECxnrtQ4AlhNZtqdmk_Qp3Dsw>
Subject: Re: [TLS] Two Multi-CDN proposals
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Mar 2019 03:19:51 -0000
On Fri, Mar 1, 2019 at 6:39 PM Nick Sullivan <nick= 40cloudflare.com@dmarc.ietf.org> wrote: > > > On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood < > christopherwood07@gmail.com> wrote: > >> On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop <mbishop@evequefou.be> wrote: >> > >> > Stephen, there are a couple complicating factors here where I think we >> all have varying knowledge gaps. >> > >> > There are two major ways of pointing to a CDN: Direct A/AAAA records >> and CNAMEs. The easiest way to handle key update complexities on the part >> of the CDN(s) is simply to CNAME the ESNI query for your domain to their >> ESNI record, but you can certainly directly host your CDN’s keys in your >> domain if you prefer. Nothing should preclude that. >> > The issue we’re trying to address is when the ESNI record and the >> A/AAAA record follow different CNAME chains and you get the records from >> different hosts. Of course, if we move to an ESNI RRType with the same >> hostname (see #105), there’s hopefully a single CNAME chain that gets >> cached at the resolver and used when looking up both queries. If they >> remain separate hostnames, it seems like it gets much easier for them to >> diverge. >> > It’s my understanding that DNSsec doesn’t play well with returning a >> subset of all extant RRs for a given name+type. However, some CDNs return >> DNS results tailored to the user’s location; the load-balancing servers >> will (in some cases) return CNAMEs to different targets based on the >> desired traffic share. That’s not a behavior that maps well to DNSsec as I >> understand it. You mention DNSsec signing your domain as part of why you >> have issues with the proposal, but I think this is an open issue beyond >> ESNI or these PRs. >> > >> > Maybe someone better-steeped in DNS/DNSsec can help us figure out how >> all that should work, and I agree with you that there are definitely bumps >> here we need to iron out – maybe those are just questions to answer, or >> maybe changes to the structure of the record are warranted. >> > >> > However, these PRs are primarily about what information should be in >> these records and how clients make use of it. I disagree with you that we >> have to resolve both questions at the same time. Let’s agree on content >> first, and spent some time separately with DNS folks to see whether the >> content can be more pleasantly arranged. >> >> Thanks all for the discussion so far! Focusing strictly on the content >> of the records and not the formatting, as Mike suggests, we >> essentially have the following: >> >> - #137 gives clients a way to detect A/AAAA+ESNI mismatch and recover, >> at the cost of another sequential DNS query for ESNI. In this change, >> A/AAAA records still control where traffic goes. >> - #136 never requires clients to send a second DNS query for ESNI >> since clients ignore the A/AAAA results. In this change, ESNI records >> dictate routing. >> >> With #137, clients willing to send a second DNS query will get ESNI >> for all supporting providers. Clients unwilling to send a second DNS >> query will only get ESNI for those providers which ensure that their >> A/AAAA and ESNI records very rarely mismatch. With #136, clients only >> get ESNI for those providers capable of building ESNI records with >> correct addresses. In theory, these providers should be the same ones >> that could ensure A/AAAA and ESNI record matching. >> >> Given this, the discussion seems to hinge on the following question: >> Are operators comfortable with the risks of letting ESNI records >> control routing. If so, #136 is probably a better design for said >> operators. If not, then #137 is probably required. > > > Thanks for the summary, Chris. > > Speaking for Cloudflare, we prefer the method described in #136 and would > be willing to implement ESNI records this way. > > I have sympathy for organizations with a preference for #137 for > debuggability reasons, but I would rather avoid situations in which the > client needs to do an additional DNS query if avoidable. > > I would support the option to include either extension based on operator > preference. > This more or less aligns with my views. >From my perspective, we know that #136 is safe, although it may be inconvenient for some operators, and it's not clear to me that #137 can be made to work without frequently incurring another serialized DNS query. If we had some evidence to the contrary, I would be somewhat more favorable to #137, though I would probably still prefer #136 for reasons of simplicity, especially as we can always add #137 later if it proves viable. -Ekr > >> Note that this does not mean we must choose between #136 and #137 >> right now. We can do both (after possibly simplifying #137!), use >> them, and see what works best in practice. >> >> Anyway, I hope this summary accurately captures the differences and >> possible tradeoffs. >> >> Best, >> Chris >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Two Multi-CDN proposals Christopher Wood
- Re: [TLS] Two Multi-CDN proposals Mike Bishop
- Re: [TLS] Two Multi-CDN proposals Christopher Wood
- Re: [TLS] Two Multi-CDN proposals Stephen Farrell
- Re: [TLS] Two Multi-CDN proposals Eric Rescorla
- Re: [TLS] Two Multi-CDN proposals Stephen Farrell
- Re: [TLS] Two Multi-CDN proposals Eric Rescorla
- Re: [TLS] Two Multi-CDN proposals Kazuho Oku
- Re: [TLS] Two Multi-CDN proposals Stephen Farrell
- Re: [TLS] Two Multi-CDN proposals Eric Rescorla
- Re: [TLS] Two Multi-CDN proposals Stephen Farrell
- Re: [TLS] Two Multi-CDN proposals Eric Rescorla
- Re: [TLS] Two Multi-CDN proposals Stephen Farrell
- Re: [TLS] Two Multi-CDN proposals Christopher Wood
- Re: [TLS] Two Multi-CDN proposals Mike Bishop
- Re: [TLS] Two Multi-CDN proposals Stephen Farrell
- Re: [TLS] Two Multi-CDN proposals Mike Bishop
- Re: [TLS] Two Multi-CDN proposals Christopher Wood
- Re: [TLS] Two Multi-CDN proposals Nick Sullivan
- Re: [TLS] Two Multi-CDN proposals Eric Rescorla
- Re: [TLS] Two Multi-CDN proposals Mike Bishop
- Re: [TLS] Two Multi-CDN proposals Eric Rescorla
- Re: [TLS] Two Multi-CDN proposals Kazuho Oku
- Re: [TLS] Two Multi-CDN proposals Kazuho Oku
- Re: [TLS] Two Multi-CDN proposals Christopher Wood
- [TLS] More issues with current ESNIKEYS DNS appro… Erik Nygren
- Re: [TLS] More issues with current ESNIKEYS DNS a… Stephen Farrell