Re: [TLS] Two Multi-CDN proposals

["Christopher Wood" <[e-mail]>]

On 4 Mar 2019, at 19:24, Kazuho Oku wrote:

> 2019年3月3日(日) 5:57 Eric Rescorla <[e-mail]>:
>>
>>
>>
>> On Fri, Mar 1, 2019 at 11:03 PM Mike Bishop <[e-mail]> 
>> 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