On Thu, Nov 8, 2018 at 6:31 PM Ryan Carboni <rya...@gmail.com> wrote:
> On Thursday, November 8, 2018, Eric Rescorla <e...@rtfm.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
