Re: [TLS] Two Multi-CDN proposals

[Eric Rescorla <[e-mail]>]

On Thu, Feb 28, 2019 at 2:50 AM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 28/02/2019 02:40, Eric Rescorla wrote:
> > On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell <
> [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.
>

No, it's merely the most challenging.




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

The vast majority of people have someone else manage their DNS, so I'm sure
some others do, but I doubt many.


> 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 really understand your point, because this *is* the expected
design.



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

Well, obviously if you bake all the functionality into the record from the
start, you won't need extensions, mandatory or otherwise. But I don't think
this piece of functionality is well enough understood to tdo that with.

-Ekr


> Cheers,
> S.
>
>
>
> >
> > -Ekr
> >
>