On 4 Mar 2019, at 19:24, Kazuho Oku wrote:
2019年3月3日(日) 5:57 Eric Rescorla <e...@rtfm.com>:
On Fri, Mar 1, 2019 at 11:03 PM Mike Bishop <mbis...@evequefou.be>
wrote:
Totally agree that we want to avoid the extra DNS round-trip as
often as possible. However, I see the options in the opposite light
– if all you need is #136, then you can put exact addresses into
#137 and get the same behavior.
Sure, but if the error rate is too high, then people will just not do
ESNI with the non-exact address version, so you've absorbed
complexity for nothing.
i'd also like to hear from CDNs about whether their address ranges
are really small enough to not make the list of ranges prohobitive.
The question is whether the additional capabilities of #137 are safe
and needed. Depending how much later #137 is added, we may wind up
needing to support both, which would be… suboptimal.
I actually don't think that's so bad. The complexity of the union of
136 and 137 isn't actually much more than the complexity of 137,
especially if the client just omits step 1 of the 137 algorithm (for
exact addresses).
I think what will swing the needle on safety – how often there’s
divergence – lies in how the record is positioned. Two problems
with the current approach that I see:
Correct me if I’m wrong, but I don’t believe the alias is
allowed to have subdomains. If www.example.com is a CNAME, then
_esni.www.example.com cannot exist, can it?
Even presuming that it did, or that it weren’t a subdomain, it
would follow its own CNAME chain which might not lead to the correct
provider.
My understanding is that there was consensus to remove _esni, just
that we didn't get around to it because of this issue.
If, however, the ESNIKeys RRType is resolved by following the CNAME
from the host, it depends on how often two queries for two different
RRTypes on the same hostname follow different CNAME chains. We have
a ready-made way to test that – A and AAAA. I have an idea where
we can get some data on that.
Great. I would be interested in seeing that.
FWIW, I am also looking forward to seeing the data, because if the
chances of responses getting out-of-sync is very low (e.g. 0.1%), I
think there's chance we might agree without having neither of #136 or
#137.
We could just use the ESNI key synchronization mechanism that was
introduced in #124 by using IP address-based certificates. That'd have
2 RT penalty (or 1 RT when TCP fast open is used), but that might be
tolerable if the probability is low.
Absent this data and objections to #136, I’ve merged the PR as a
viable mitigation to the multi-CDN problem. We can continue iterating on
#137 and work on collecting this critical data as needed in parallel.
Best,
Chris
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
