Re: [TLS] Two Multi-CDN proposals

[Mike Bishop <[e-mail]>]

"The issue" the PRs are attempting to solve, not in terms of ESNI all-inclusive.  I think we're on the same page, then, except that I'm confused by two things in your reply that appear to be contradictory:  You want to address the content "and structure" of ESNIKeys now, but in the next paragraph reiterate that you're fine leaving what I see as the structural parts for later.

Reading through the thread again, I think I see at least one concrete issue with the current PRs that you raised:  The PRs currently assumes that they get back a single ESNI record and one or more A/AAAA records.  Depending on the deployment, it's possible that there are multiple ESNIKeys records and the draft explicitly permits this, but PR#137 currently does not describe the handling for that.  (PR#136 doesn't really need to, since it disregards the A/AAAA records.)

However, the more common deployment scenario for multi-CDN would be a single record (per version, eventually) from each CDN; each client would receive only one.

-----Original Message-----
From: Stephen Farrell <[e-mail]> 
Sent: Friday, March 1, 2019 3:53 PM
To: Mike Bishop <[e-mail]>; Eric Rescorla <[e-mail]>
Cc: <[e-mail]> <[e-mail]>
Subject: Re: [TLS] Two Multi-CDN proposals


Hiya,

On 01/03/2019 23:19, Mike Bishop wrote:
> Stephen, there are a couple complicating factors here where I think we 
> all have varying knowledge gaps.
Doubtless. I confess lots of ignorance as to how CDNs operate.

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

I agree that we need something that works for both. As there are meta-issues with some privacy mechanisms encouraging more centralisation, I think it's important that we be explicit in considering such, as we've been doing here. (To simplify and paraphrase it a bit: part of my position is that "nothing should preclude" is too weak - ESNI needs to work for both - to the extent possible.)

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

I agree with all you say except the first one of the two words "the issue" - there is more than one issue at play I'd say:-)

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

It seems I didn't explain myself so well. For my setup the fact that I support DNSSEC (and hence periodic re-signing) makes it easier for me to support periodically acquiring and (re-)publishing ESNIKeys from multiple sources. So having an existing DNSSEC setup helps here.

Other than that, I'm not sure DNSSEC and ESNI have so much to do with one another, given that DNSSEC really doesn't provide any cryptographic linkage when things like MX or CNAME are used in the DNS.

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

I'm not quite sure what you mean but I can think of two things:-

1. I have argued about how the content and structure of ESNIKeys can affect deployment models and manageability, and do think that now is the time to consider both. I maintain that position. And my main points in this thread have all been about how the structure of ESNIKeys could affect deployment models.

2. I think I explicitly said I'm fine with the encoding (TXT vs new
RRTYPE) being handled later. The same goes for a lot of other aspects of the structure of ESNIKeys (but not all). There were a bunch of mails though, so it's likely easy to miss that;-)

Cheers,
S.


> 
> 
> 
> -----Original Message----- From: TLS <[e-mail]> On Behalf 
> Of Stephen Farrell Sent: Thursday, February 28, 2019 2:50 AM To: Eric 
> Rescorla <[e-mail]> Cc: <[e-mail]> <[e-mail]> Subject:
> Re: [TLS] Two Multi-CDN proposals
> 
> 
> 
> 
> 
> Hiya,
> 
> 
> 
> On 28/02/2019 02:40, Eric Rescorla wrote:
> 
>> On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell
> 
>> <[e-mail]<mailto:[e-mail]>>
> 
>> wrote:
> 
>> 
> 
>>> 
> 
>>> Hiya,
> 
>>> 
> 
>>> On 28/02/2019 01:41, Eric Rescorla wrote:
> 
>>>> I think you're misunderstanding the scenario here: we have two CDNs
> 
>>>> A and B, and some switching service in front, so that when you
> 
>>>> lookup
> 
>>> example.com,
> 
>>>> you get a CNAME to A or B, and then you get the ESNIKeySet
> 
>>> 
> 
>>> (ESNIKeySet is a type you've just invented I guess?)
> 
>>> 
> 
>> 
> 
>> No. I forgot it was named ESNIKeys
> 
>> 
> 
> 
> 
> Phew:-)
> 
> 
> 
>>>> for A or B as
> 
>>>> the case may be. So you're not going to get both ESNIKeys values.
> 
>>> 
> 
>>> Yes, that's not the model I had in mind. I don't recall that
>>> having
> 
>>> been written down but maybe I missed it. (Where should I look?)
> 
>>> 
> 
>> 
> 
>> I believe this was discussed in Bangkok during the discussion of
> 
>> problems with the current structure.
> 
> 
> 
> FWIW, I didn't take from that discussion that we only want that model
> to be supported, but it may have passed me by if that was stated.
> 
> 
> 
>>> The model I had in mind was where the hidden site has it's own
>>> DNS
> 
>>> operator but >1 CDN/front-site with each of those having a
>>> private
> 
>>> ESNI value. (And if there's some front-end DNS cleverness, it'd
>>> kick
> 
>>> in when the CNAME from #137 is being chased down.)
> 
>>> 
> 
>> 
> 
>> I don't see how this is conflicts with what I said above, as that
> 
>> server still needs to ensure consistency.
> 
> 
> 
> I don't think mine conflicts with the model you describe, but I do
> think it has different consequences for how we ought structure the
> ESNIKeys stuff.
> 
> 
> 
> To be more specific, say in my model I have example.com and want to
> see ESNI used for www.example.com<http://www.example.com> and I
> publish the zone for example.com including ESNIKeys.
> 
> 
> 
> Now I want browsers to be able to use either cdn1.example or
> cdn2.example to front for www.example.com<http://www.example.com>
> where those are independent CDNs.
> 
> 
> 
> So I need to update my DNS zone periodically whenever one or other
> CDN changes their ESNI public key share.
> 
> In my tiny little case doing this for a few domains, I already have a
> small infrastructure that allows me to do that kind of thing because
> of the need for regular DNSSEC re-signing. (Mine currently works at a
> weekly or daily cadence, but doing it hourly would be fine.)
> 
> 
> 
> I'd like to do that via a simple update to my zone files without
> having to unpack and re-pack the data structures I get from cdn1 or
> cdn2. Now sure, I could write a new tool to munge together what I get
> from the CDNs but that's more work (that could go wrong) and doesn't
> match my current work flows. And I suspect others may operate
> similarly.
> 
> 
> 
> That's what leads me to think that we'd be better off to have
> multi-valued answers when a browser looks up the RRset at
> _esni.www.example.com with each separate value matching one ESNI
> public share (or one CDN, though I'd argue for one share per zone
> file stanza).
> 
> 
> 
> I don't think that conflicts with your model where
> _esni.www.example.com is one or another CNAME at a given moment but
> it does differ from it.
> 
> 
> 
> There is however some dependency on #137 to get what I want I guess
> using the host_pointer to get the privacy benefit of using a CDN. I
> guess I might need to publish yet another ESNI public share that
> matches the private available at the A/AAAA of
> www.example.com<http://www.example.com> as well as those from the CDN
> even though that may get me less privacy benefit compared to browsers
> who go to cdn1 or cdn2. (It's possible that I'm reading
> 
> #137 wrong though, but I read it as supporting the kind of setup I
> describe here.)
> 
> 
> 
>> In any case, the model I am describing has a consistency problem
>> which
> 
>> needs to be addressed.
> 
> 
> 
>>> PS: I nonetheless maintain my points about the current ESNIKeys
> 
>>> structure - it's over generic and over complex and these PRs can
>>> only
> 
>>> make that worse:-)
> 
>>> 
> 
>> 
> 
>> Yes, I am aware this is your opinion, but I don't agree.
> 
> Fair enough:-) Personally I think that if we support the kind of
> model above, such simplifications may well naturally fall out of that
> work but we'll see I guess.
> 
> For example, I think that'd allow re-structuring the ESNIKeys thing
> so the host_pointer in #137 no longer needs to be an extension and
> hence we don't need the concept of mandatory/critical extensions at
> all.
> 
> 
> 
> Cheers,
> 
> S.
> 
> 
> 
> 
> 
> 
> 
>> 
> 
>> -Ekr
> 
>>