On Mon, Dec 11, 2017 at 5:03 PM, Ryan Sleevi via dev-security-policy < [email protected]> wrote:
> On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote: > > While I understand that it may formally be beyond the scope formally to > > consider this in discussion with EV UI handling, I think some > consideration > > to ecosystem harm is appropriate here. > > > > If we eliminate EV UI, we have reduced the scope of WebPKI to domain > > validated certificates (in any pragmatic sense, anyway). > > That already is all the Web PKI is. Full stop. > > The origin is the scheme, host, port. It's not the validation method. The > validation method does not constitute a security boundary on the Web or in > the Web PKI, so all there is is domain validation. > This argument has been presented before, and was not previously sufficiently compelling to effect change. > > Everything else is a quasi-boundary that is full of more holes than the > most exquisite of cheeses. Every attempt to somehow redefine that as a > different boundary has been unable to do so. Even the introduction of EV > called for the separation of scheme, because without that, EV provided no > direct security value. > > So why are we promoting EV as a boundary or with UI surface? Under the > mistaken assumption that the user is always inspecting the URL at every key > stroke and interaction and sub-resource load. That's actively user hostile, > and damaging to any credible discussion of security. > The goal, I should think, would be for the user to be able to identify that the principal resource at the URI in the browser window is pulling in resources under the direction and responsibility of "EV Cert Holder", who hopefully work to minimize third party resources. > > > Conveniently. if the domain validation is all important, there is, for > any > > given domain, a single entity authoritatively enshrined to answer at any > > given moment to whom and when a certificate may issue: the currently > > attached domain registrar. > > > > Taken ad absurdum, that's where an exclusively domain validation > landscape > > leads. > > ad aburdum isn't necessary - that's exactly how it should work! And it's > absolutely true that third-party CAs act as an indirection between this > registrar and the issuance of a certificate - an independent attestation of > this relationship. > Let me be sure I understand: the third party CAs add value or not? In this picture you've painted, I think not. That indirection has less value as "an independent attestation" than it has cost or potential cost in points of exploit. There is little security if any over the communications between the DNS infrastructure, the registry, and the CAs. Generally, it's over insecure and MITMable DNS queries. And there's no independent attestation to trust the CAs word on here: let's face it - the registry is still the authoritative answer, even if they blatantly engaged in revisionist history. So, if we're headed to objectively best security, should we not just be working toward the registry as a CA? Conveniently, we can even name-constrain each registry to their own TLDs. > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
