Re: [TLS] Enforcing Protocol Invariants

[Eric Rescorla <[e-mail]>]

On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni <[e-mail]> wrote:

> On Thursday, November 8, 2018, Eric Rescorla <[e-mail]> wrote:
>
>>  It's also worth noting that in practice, many sites are served on
>> multiple CDNs which do not share keying material.
>>
>>
> Encrypting common knowledge is cargo cult fetishism for cryptography. The
> files could be sent unencrypted, and protected using subresource integrity.
> If you are sharing the same data to multiple second parties to serve to a
> single third party, the value of encryption is less than zero.
>

I believe you are misunderstanding me. The issue is not about
confidentiality of the records but about correctness.

Consider the case where example.com which is hosted on two CDNs, X and Y. X
and Y have different private keys (for the reasons you indicate) as well as
different crypto configurations. The client does an A/AAAA lookup for
example.com and gets an A for X and then does a TXT lookup for example.com
and gets the TXT for Y. This creates failures. We've spent quite a while
working on this problem for ESNI and there aren't a lot of great answers
right now. It seems like your proposal would suffer from the same issue.


In any case, Eric, you inadvertently contradict yourself. The whole point
> of WebPKI is to certify trust, and has been an issue over the years. But
> CDNs act as a intermediary between the creator of the content and the end
> user. CDNs do not have as strict requirements as do CAs in terms of
> auditing, and have their own issues outside the scope of this conversation.
>

Well, I agree that this is out of scope, but the guarantees that the WebPKI
claims to enforce (at least for DV) is effective control of the domain
name, and a CDN acts as the origin server for a given domain and hence
effectively controls it. I appreciate that many people don't like this, but
it's essentially the only design that's consistent with having the CDN act
for the origin, which is at present basically essential for good
performance.


In any case, TLS 1.3 won’t reach widespread adoption for another few years,
>

I don't know what you consider "widespread", but presently both Chrome and
Firefox support TLS 1.3, and our data shows that about 5% of Firefox
connections use TLS 1.3. Chrome's numbers are similar and the numbers from
the server side perspective are higher (last time I checked, Facebook was
reporting > 50% TLS 1.3).

-Ekr