RE: Security Model, Secondary Certs, and ORIGIN

Based on these musings, Erik and I have published a draft suggesting that ORIGIN goes further than the community now seems comfortable with and discussing the reasons in more detail.  Please see the published draft<https://tools.ietf.org/html/draft-bishop-httpbis-origin-fed-up-00> or the working copy<https://mikebishop.github.io/origin-fed-up/draft-bishop-httpbis-origin-fed-up.html>.  You can provide feedback on-list, privately, or via GitHub<https://github.com/MikeBishop/origin-fed-up>.

There was limited list response to the original message, hopefully due to the proximity of the holidays, but I did get an off-list answer to the question about which clients implement: Firefox honors ORIGIN without DNS; I am unaware of any other user agent that has chosen to honor ORIGIN "blindly" at this point.

From: Mike Bishop
Sent: Friday, November 16, 2018 11:26 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Security Model, Secondary Certs, and ORIGIN

One of the things I've been wrestling with following the most recent IETF discussion is a resurgence of the question about whether DNS is, in fact, a contributor to security.

In the ORIGIN spec, our conclusion was that it wasn't.  "In the cert we trust" - if you have a valid certificate and ORIGIN claims ownership, you MAY consider it sufficient.  We handwaved at "some alternative means to establish a high degree of confidence," like SCT and OCSP - but the certificate is the linchpin of our trust model, if you believe RFC 8336.  While rough, we reached consensus on that.

However, the different security concerns about Secondary Certs fundamentally all come back to an idea that certificates can be compromised in various ways, and OCSP/SCT have been considered insufficient mitigation for cert compromise during these discussions.  Unless you check DNS, these attacks will continue to exist.  We can do multiple iterations of creative chaining dances to shift the thing which must be compromised to somewhere we believe is stronger, and there's some value in that.  But at the same time, the different forms of attack being brought up ultimately lead me to think we need to be asking a more fundamental question:

Did we screw up?

That is, have we now convinced ourselves that these attacks which DNS, though weak, helps prevent actually matter?  Certainly my understanding is that there has been limited uptake of the 8336 "MAY avoid consulting DNS" among clients, which argues that the marketplace isn't confident we got this one right.  Can I ask which clients implement that, at this point?

I understand that one of the drivers of that change was to increase user privacy by leaking less information to the network and the DNS server through these saved DNS resolutions.  The network leakage concern now has a better solution through the use of DoT and DoH.  The leakage to the DNS server itself is potentially addressable through the ongoing discussions about "resolverless" DNS, where there might eventually be a way for the server to send you the (signed) DNS records in-band, bypassing the DNS server.

As a result, I'm coming to believe that ORIGIN got it wrong, and we need to update that document to close the hole.

- Mike Bishop