Re: [TLS] Two Multi-CDN proposals

Despite the additional complexity of #137, I think it's probably the better approach (and I would be fine with the simplification, if that makes it more palatable).  Particularly when multi-CDN is used, there's a lot of logic involved in generating the "right" A/AAAA record in response to a request.  #136 essentially lets the ESNIKeys result override the A/AAAA, which means ESNIKeys needs to be equally tailored and duplicate all the existing logic for a new record type.  In #137, the ESNIKeys essentially contains enough information to check that the A/AAAA results came from the same entity as the ESNIKeys result but leaves the DNS complexity where it already exists.  (It has the option to override, and removing that would be the simplification.)

The tripping point of #137, however, is that it may need a recovery path (i.e. a second A/AAAA resolution) in case the records come from mismatched providers.  We don't currently have data on how often that would happen -- whether it's 10% or 0.001% of the time would make a big difference.

-----Original Message-----
From: TLS <tls-bounces@ietf.org> On Behalf Of Christopher Wood
Sent: Wednesday, February 27, 2019 8:18 AM
To: <tls@ietf.org> <tls@ietf.org>
Subject: [TLS] Two Multi-CDN proposals

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

#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

TLS@ietf.org<mailto:TLS@ietf.org>

https://www.ietf.org/mailman/listinfo/tls