On Wed, Feb 27, 2019 at 4:36 PM Mike Bishop <mbis...@evequefou.be> wrote: > > 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.
Thanks, Mike! I agree with the technical descriptions of both approaches. Since each design uses an extension, could we pursue them simultaneously? I'm not sure we must necessarily choose one or the other here. (Perhaps I should have emphasized that in my original message. Oops.) Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
