Ryan, Browsers have never agreed to anything ever. Browsers do not have thoughts. Browsers are not sentient. Not even in Westworld. Some engineers working for a Browser company have come to the conclusion that they can better meet their page load performance goals if they dispense with safety checks.
Security is a property of systems, not technologies. I was there when we designed this technology which was originally developed for purpose of making users confident that online commerce was secure. It was only after complaints from myself and Alan Schiffman that this goal was changed to making online commerce at least as secure as traditional bricks and mortar commerce. The browser folk got it wrong then at least so I don’t think we should automatically assume that today’s browser engineers are always right either. Since then SSL/TLS has been used as a security Swiss Army knife. Which is good in that it has added security to many situations where security was otherwise absent. But often there is a mismatch and the security doesn’t really work as well as it should. And I don’t see this particular proposal doing anything much to close up the gap between security needs and security controls. Of course reducing the validity interval will improve some security metric by some iota. But the real purpose of the change is to react to the SHA-1 circumstance. Which is fine. As an industry, we failed users and certificate subjects. Right now I am getting certificate security warnings from Mass DoT due to a validly issued 3 year certificate that uses SHA-1. That should not be acceptable to us. But where does the problem really lie and does reducing the certificate validity window really address it? I predicted a bumpy transition to SHA-2 in 2002 when I noticed that browsers were not adding it to the list of supported hashes. Which was even more strange at the time as the crypto libraries were filled with all manner of garbage algorithms. This was still an uphill struggle after the 2005 Wang et. al. attack was published. I developed and proposed a scheme that would enable a smooth transition from SHA-1 to SHA-2 and nobody was interested until the SHAppening in 2015 when it was suddenly decided that this had to happen yesterday and the CAs were of course to blame for not insisting on issuing certificates that the browser providers had refused to support. Right now I am trying to persuade people that we should be supporting SHA-3 as a backup to SHA-2 but of course nobody is taking any notice. Not even the people insisting that we must wind down the validity interval to a year to enable faster changeover. What we need is a technology architecture and a technology roadmap. The technology architecture would begin with a set of high level requirements such as: * Stability: It must be possible for parties to make technology choices with a guarantee of support for X1 years * Validity: It should be possible to invalidate certificates used by bad actors within X2 hours * Perfomance: If used at Internet scale (every Web site covered) impact on client would be no more than X3 ms latency and X4 Kb data per update. * Traffic Analysis: The Internet security infrastructure should resist traffic analysis. All of these requirements can be met by existing technology albeit not with existing standards. One thing is certain, we are not going to get from where we are now to where we want to be through a purely incremental approach. One point of a roadmap would be to plan deployment of groups of technology that in combination provide a quantum upgrade on our current base. Much as EV did when it was developed. It also represents a wishlist for bodies such as the IETF to deliver on. Traffic analysis is a very hard problem to solve because every step you take has a cost and there is no value unless you close almost every crack through which data might leak. Its very easy to bash OCSP, harder to deploy DPRIV which closes the much larger hole in DNS. In practice of course, a traffic analysis resistant transport layer requires at minimum all of deployment of DNSSEC, use of DNS keys to encrypt the SNI exchange and OCSP stapling or very short lived certs. Another point of a roadmap is to keep ourselves honest. I think that we should make a commitment to an infrastructure that people can build on relying on it to be stable over a five year period at the very least. Which is actually a rather short time for a non cryptographic infrastructure. Taking that decision would do a lot more for Internet security than winding down the issue interval because it would force us to be a lot more proactive in planning for deployment of successor algorithms. In fact we would probably decide now is the time to deploy SHA-3 > On Feb 3, 2017, at 4:10 PM, Ryan Sleevi via Public <[email protected]> > wrote: > > Kirk, > > While I understand you have a different view of how browsers should work, I > think it might be more useful and productive to this discussion to > acknowledge that browsers (and to the broader extent, relying parties) have > disagreed your premise - and more generally, security practitioners outside > of the Antivirus Industry (in particular) recognize your approach to security > as flawed. > > However useful this discussion, though, it might be more useful if CAs could > focus on specific reasons or challenges that the ballot would impose, > particularly considering the (many) benefits I outlined in my reply to Doug. > > Concretely, I think there's an onus on CAs to show that these (considerable > and meaningful) benefits are somehow overshadowed by the cost. To date, we've > yet to see any evidence or counter-point that somehow users would be _less_ > secure with the proposal. > > On Fri, Feb 3, 2017 at 12:07 PM, Kirk Hall via Public <[email protected] > <mailto:[email protected]>> wrote: > Richard, I’ve always thought that if revocation checking worked in (say) 85% > of OCSP or CRL queries and revealed to users that a bad cert had been revoked > and a site should not be trusted, then we (CAs and browsers) were > successfully protecting 85% of users who were visiting the bad site. To me, > that is a huge win. If we can work to improve that figure to 98% or 99.9% > over time or with new methods, even better. But warning 85% of users of a > revoked cert today is way better than warning 0% of users of a revoked cert > as happens today when browsers don’t even bother checking for revocation. > (It’s like a highway commission saying “This guardrail won’t prevent 100% of > accidents, so we won’t put up a guardrail at all” – if the guardrail stops > 99% of accidents, it’s a good thing.) > > > > If browsers always tell relying parties “Revocation checking doesn’t work”, > then I guess that’s what relying parties will tend to believe over time – so > no use asking what relying parties believe . But if revocation checking > works in the great majority of cases where it’s tried, then it is a major > tool for user security that should be restored by browsers. > > > > (And let’s not raise the issue “revocation checking can be blocked in a > compromised environment, MITM, etc. so it’s never even worth trying in any > environment” – that an extremely weak argument for giving up all revocation > checking in the normal internet environment that the vast majority of users > encounter, where revocation checking is not blocked and users can receive > warnings of a revoked certificate.) > > > > From: Public [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Richard Barnes via Public > Sent: Friday, February 3, 2017 11:41 AM > To: CA/Browser Forum Public Discussion List <[email protected] > <mailto:[email protected]>> > Cc: Richard Barnes <[email protected] <mailto:[email protected]>> > Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of > Certificates > > > > Is there anyone on the relying party side of the universe that believes > revocation works? Even among browsers that send OCSP requests, none of them > hard-fail if it doesn't work, because in practice, OCSP servers are so awful > that HTTPS would become unusable. So OCSP is still, as AGL says, a seat belt > that breaks when you crash. Seems fair to call that broken. > > Even if OCSP were magically to become usable, though, (or some replacement > for it) this ballot would still be necessary for all the other reasons that > have been discussed here. > > > > > > On Fri, Feb 3, 2017 at 11:34 AM, Rich Smith via Public <[email protected] > <mailto:[email protected]>> wrote: > > Ryan, since you're using your age old FUD "revocation doesn't work" (because > certain browsers have chosen not to consult revocation information) as part > of the reasoning as to why this ballot is necessary, I think it's quite > germane to the discussion. > > > > On 2/3/2017 11:38 AM, Ryan Sleevi via Public wrote: > > > > > > On Fri, Feb 3, 2017 at 9:11 AM, Rob Stradling <[email protected] > <mailto:[email protected]>> wrote: > > Ryan, what targets (filesize/performance/reliability/reachability/etc) would > CAs need to meet before it would become viable to reintroduce CRLs to the > WebPKI (i.e., for Chrome to start checking CRLs and hard-failing if they're > unobtainable)? > > > > Happy to have that discussion at another time, but it's not germane to the > discussion at hand, as I clearly indicated in the original message. It's > necessary, but not sufficient, to have that, and we're not presently > proposing addressing all the other necessary conditions. Baby steps. > > > > > > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public> > > > > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public> > > > > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public> > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
