Re: [TLS] Two Multi-CDN proposals

[Stephen Farrell <[e-mail]>]

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