Re: [TLS] Two Multi-CDN proposals

[Stephen Farrell <[e-mail]>]

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.

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

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