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. > > 3) The status vulnerability window needs to be no longer than 48 hours > for a machine with an accurate clock That's an opinion, and not a hard requirement memorialized in the current Baseline Requirements or Mozilla program. So I don't think it's fair or reasonable to introduce it as a requirement upon some new scheme or proposal. > > 4) The scheme must tolerate some degree of clock skew, though the > amount might vary over time. That's up to the server operator, not the CA, and whether or not the solution is viable for them. Which is to say, a solution that tolerates no degree of clock skew is still immensely viable for a group of people. The more clock skew supported, the more viable it becomes for others, but that is NOT a gating factor to the overall scheme. > > > 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. > > At worst we reword the requirements on browsers to say that they have > to verify that the status is current and not specify how. Short lived > certs would automatically qualify. > > > Must Staple and short lived certs are pretty much the same as far as > the security requirements go. The difference is that the server > requirements for supporting stapling with must staple are pretty > simple. All that is needed is that the server specify the must staple > extension when the certificate is applied for (just a flag on the key > generator) and then the server pulls the OCSP token from the AIA > extension every n hours which is already implemented almost > everywhere. > > 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. > > > 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. The correct answer is hard fail. Any other answers and we'll be back here again in 5 years with the same issues. > > 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. > > > The simplest way to do cert update would be for the server to keep the > same key throughout and just issue fresh certs for the same old key. > > A much better approach that provides a lot of robustness in all sorts > of ways is to rotate the private key with each new certificate. Under > one scheme the server would have some means of authenticating the cert > update request to a CA (probably a long term RSA or ECC key pair). > > But in a large server farm where outsourcing etc is involved you might > want to have a scheme that makes use of trustworthy hardware to bind > unique keys to particular hardware in a manner that prevents > extraction. > > I have a scheme of this type described here... > > https://datatracker.ietf.org/doc/draft-hallambaker-omnipublish/ > > > > 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
