On Thu, Sep 4, 2014 at 6:43 PM, Ryan Sleevi <ryan-mozdevsecpol...@sleevi.com> wrote: > On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote: >> Some constraints: >> >> 1) Any new scheme has to work equally well with legacy browsers and >> enabled browsers. > > Sure. However, this requires a definition of legacy. > >> >> 2) Ditto for legacy servers and this is actually a harder problem as >> upgrading a server can force a complete redesign if they are using a >> middleware layer that has changed radically. > > Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as > an option. No one's requiring they exclusively limit issuance to it. > There's no concern for legacy servers. If you're a legacy server, you > don't use this. It's that simple.
It is still a problem. The point I am trying to get across here is that there are very few good reasons for an end user sticking to an obsolete browser and almost all would upgrade given the choice. This is not the case for servers and there are lots of folk who will complain if they are forced to upgrade their server because that might require them to change their PHP version which in turn requires them to completely rework a ton of spaghetti code piled on top. >> Because of (1), the AIA field is going to have to be populated in EV >> certs for a very long time and so we probably don't need to raise any >> of this in CABForum right now. Lets do the work then let them follow >> the deployment. A browser doesn't have to check the AIA field just >> because it is there. > > I'm not sure I agree with your conclusion for 1. As noted elsewhere, a > short-lived cert is effectively the same as the maximal attack window for > a revocation response. That's it. The AIA can be dropped if they're > equivalent. It can be dropped as far as security is concerned. But that is only going to save a few bytes and might cause legacy issues. So why make being allowed to drop it a major concern at this point? Dropping AIA is useful for the CA as I don't need to bother with OCSP at all. But I can only drop AIA if it is not going to cause legacy browsers to squeak about a missing OCSP distribution point. If there are browsers that give appropriate treatment to short lived certs then I am sure getting CABForum to update the BRs etc. is not going to be hard. All I am saying here is that is not a critical path concern. >> Short lived certs are just as easy in theory BUT they require some new >> infrastructure to do the job right. At minimum there needs to be a >> mechanism to tell the server how to get its supply of short lived >> certificates. And we haven't designed a standard for that yet or >> really discussed how to do it and so it isn't ready to press the fire >> button on. > > I disagree here. What's at stake is not the particular mechanisms of doing > so, nor would I endorse going down the route of standardizing such > mechanisms as you do. I would much rather see the relevant frameworks - > Mozilla and the BRs - altered to support them, and then allow site > operators and CAs interested in this model to work to develop the > infrastructure and, based on real world experience, rough consensus, and > running code, rather than idealized abstractions. I am not interested in issuing any product until my customers can use it. And I don't see how they can use it until the cert update process can be automated. >> What I suggest browsers do right now is >> >> 1) Join in the IETF discussion on the TLS/PKIX lists saying that you >> support my TLS Feature extension proposal aka MUST STAPLE. >> >> 2) Read and comment on the proposal you have just committed to. >> >> 3) Implement an appropriate response to a certificate that specifies a >> MUST STAPLE condition when the server does not staple. This could be >> (1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard >> fail if it does not succeed or (3) choose randomly between options 1 >> and 2 so as to disincentivize CAs misusing setting the flag to force >> hard fail. > > This is something you should nail down before 1 or 2. OK, if I have to nail it down I will pick 1. > The correct answer is hard fail. Any other answers and we'll be back here > again in 5 years with the same issues. That is my preference. >> 4) Implement a mechanism that regards certificates with a total >> validity interval of 72 hours or less to be valid without checking. I >> do not expect this feature to be used very soon but implementing the >> feature in the browser is probably a gating function on starting the >> server folk thinking about the best way to implement the cert update >> feature. > > And implementing it in policy is the gating function before thinking about > implementing it in the server or the browser. I don't see the need to gate on policy changes. What do you think stops me issuing a 72 hour certificate today? I can't think of anything. >> Rotating the server private key every 24 hours practically eliminates >> key compromise due to a server or hard drive being disposed of within >> the cert validity interval. It vastly increases the cost of pervasive >> attacks against well known keys. It also works a lot better for cloud >> computing. > > Which are a different, and valuable, set of mitigations, but orthogonal > the key issue at hand. > > That is, I would like to see the world rotate keys on the regular, but I'm > not at all willing to throw the baby out with the bathwater and require > it. Which is why I mentioned the simple approach. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
