Re: [TLS] Two Multi-CDN proposals

[Stephen Farrell <[e-mail]>]

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 and the set of all of those should be in the RRset
returned when the ESNIKeys are queried.

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 said, we can fix that later I guess, even though we
will have to fix it sometime. (Fixing it now would be better!)
So I regard these ESNIKeys syntax decisions as only holding
temporarily.

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.

If #137 is adding mandatory extensions that are analogous
to X.509 extension criticality, then I think that's an
error. Despite good arguments, that has not worked out well
and this seems like the same mistake. (But as stated above,
I think all syntax here is temporary until we've made it
DNS admin friendly which it is not.)

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, so why not
do that now too, as we're modifying it? 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). I also think if we did
that we'd be able to simplify the ESNIKeys structure a
good bit all of which should lead to more robust and
simpler code. My current code for handling ESNIKeys is
very complex and long even though I've ignored the supposed
ways in which things can be extended - were I to have to
add real extension handling, it'd be even worse. Changing
to >1 RR value in the answer could make all this an awful
lot simpler and much better match the multi-CDN (or more
properly multi-private-value) scenarios.

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
>