Re: [TLS] Two Multi-CDN proposals

[Eric Rescorla <[e-mail]>]

On Wed, Feb 27, 2019 at 5:24 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> First, I think both are wrong:-)
>
> If there are really different ESNI private value holders,
> then each of those should provide separate ESNIKeys RR value
> instances


Yes, this is the idea


and the set of all of those should be in the RRset
> returned when the ESNIKeys are queried.
>

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 for A or B as
the case may be. So you're not going to get both ESNIKeys values.



> Requiring different private value holders to find some
> entity to wrap up all their crap into one single TLS blob
> is not, IMO, a good design.
>

That's not the way this works.




> On 27/02/2019 16:18, Christopher Wood wrote:
> > Hi folks,
> >
> > Below are two PRs that seek to address the multi-CDN issue discussed
> > on this list and in meetings:
> >
> >    1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136
> >    2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137
>
> I'm not sure of the details of #137 but I think I prefer
> that one a bit. I suspect either of them will be a pain to
> code given how we'll be mixing names and addresses.
>
> #136 seems broken to me in that it gives the new AddressSet
> invention priority over A/AAAA resolution. I think that'd
> need much more justification as it essentially calls for
> duplicating A/AAAA information over two administrative
> domains which seems like a recipe for failure.
>

This is not correct for the reasons I indicated above. What happens is that
the terminal CDN is responsible for publishing a record with its keys and
its A/AAAA values. Indeed, the source of the problem we are trying to solve
is that you might in successive resolutions get the CNAME for A and B, thus
having a keys/A mismatch.




>
> My reason for preferring #137 is that (if I'm reading it
> right, and I'm not sure!), it resolves a CNAME and then
> compares the resulting A/AAAA acquired via normal CNAME
> chasing to a mask from the ESNIKeys stuff. I think that
> is a better approach than replicating A/AAAA values inside
> a novel repetitive structure like ESNIKeys.
>
> Lastly, we will need to fix the TLS-developer-friendly
> but DNS-admin-unfriendly ESNIKeys structure,


[Citation needed]



IMO the way to do
> that is for each ESNI private value holder's stuff to be
> a separate RR value in the RRset (and so each is likely a
> separate stanza in a zone file).


This seems to rest on the same misunderstanding of the scenario in question.

-Ekr


So in summary:
>
> - both are wrong:-)
> - if I had to pick one to proceed with temporarily,
>   I'd go with #137 despite it being unclear
> - I'd rather we fix the ESNIKeys to be DNS friendly
>   now too and not wait to have to inevitably fight
>   that battle later (but fight I will:-)
>
> Cheers,
> S.
>
> >
> > #136 implements the combined or stapled record approach discussed
> > several times, most recently in [1]. It includes these via an ESNIKeys
> > extension. #137 builds on this design with a mechanism that lets
> > clients detect and recover from A/AAAA and ESNI mismatch (if desired).
> > It is certainly more complex in several respects. A third variant,
> > which is not (yet) in PR form, is a simplification of #137 wherein
> > ESNIKeys addresses are only used as filters, instead of filters *or*
> > complete addresses.
> >
> > We are asking for feedback on these PRs, as we would like to merge one
> > of them for the next draft version. As #136 is simpler and permits
> > extensibility, that is the current preference.
> >
> > Thanks in advance for your feedback.
> >
> > Best,
> > Chris (no hat, on behalf of the authors)
> >
> > [1]
> https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>