NSS/PSM improvements - short term action plan
Sid Stamm
After the few meetings and a couple of hours of discussion in the last
two days, we've made a short list of desired upgrades for NSS/PSM for
the near term. This message should hopefully serve as a summary of the
technical bits that -- based on the discussions -- seemed most urgent.
Here they are, prioritized into three buckets:
- A (things we want soonest)
- B (things we want fairly soon)
- C (things we want, but after A and B are done)
Bucket A:
- Move to libpkix for all cert validation (bug 479393)
- Complete active distrust in NSS (bug 470994)
- Implement callbacks to augment validation checking (bug 644640)
- Implement subscription-based blocklisting of certs via update ping
(remove need to ship patch)
Bucket B:
- Implement OCSP Stapling (bug 360420)
- Implement date-based revocation (distrust certs after specific date)
- CA locking functionality in HSTS or via CAA
Bucket C:
- Disable cert overrides for *very old* expired certs (might not be in
any CRLs anymore)
Cheers,
Sid
Adam Barth
> After the few meetings and a couple of hours of discussion in the last
> two days, we've made a short list of desired upgrades for NSS/PSM for
> the near term. This message should hopefully serve as a summary of the
> technical bits that -- based on the discussions -- seemed most urgent.
>
> Here they are, prioritized into three buckets:
> - A (things we want soonest)
> - B (things we want fairly soon)
> - C (things we want, but after A and B are done)
>
> Bucket A:
> - Move to libpkix for all cert validation (bug 479393)
> - Complete active distrust in NSS (bug 470994)
> - Implement callbacks to augment validation checking (bug 644640)
> - Implement subscription-based blocklisting of certs via update ping
> (remove need to ship patch)
>
> Bucket B:
> - Implement OCSP Stapling (bug 360420)
> - Implement date-based revocation (distrust certs after specific date)
> - CA locking functionality in HSTS or via CAA
^^^^ There's significant interest in this feature from chrome-security
as well. We have a prototype implementation of the backend in Chrome
that you can drive through some UI, but we don't have any syntax for
turning it on from the network yet. Let me know if you'd like to
discuss further.
Adam
> Bucket C:
> - Disable cert overrides for *very old* expired certs (might not be in
> any CRLs anymore)
>
> Cheers,
> Sid
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
Wan-Teh Chang
mozilla.dev.tech.crypto is the newsgroup for NSS and PSM.
Wan-Teh Chang
Jean-Marc Desperrier
>> - CA locking functionality in HSTS or via CAA
> ^^^^ There's significant interest in this feature from chrome-security
> as well.
What about EV locking ?
How does a site change CA after he's started enabling CA locking.
Would you enable multiple CA locking so that he'd start by adding the
new CA during a while when still using the old cert, and then hope for
the best after making the switch ?
Adam Barth
> On 09/04/2011 00:52, Adam Barth wrote:
>>>
>>
>> ^^^^ There's significant interest in this feature from chrome-security
>> as well.
>
>
> How does a site change CA after he's started enabling CA locking.
> Would you enable multiple CA locking so that he'd start by adding the new CA
> during a while when still using the old cert, and then hope for the best
> after making the switch ?
All good questions. We're still in the experimental phase, so we
haven't worked out all the details yet.
Rather that CA pinning, specifically, we've been experimenting with
certificate pinning, with the approach that you can pin any
certificate in the chain. For example, you can pin your leaf
certificate, or you pin your CA's certificate. The only requirement
is that future certificate chains MUST include that certificate. That
effectively gives you EV pinning, CA pinning, and leaf-certificate
pinning in one mechanism.
In addition to thinking about orderly transitions to new certificates
(as you mention), there's also the case of disorderly transitions.
For example, what happens if the site's private key gets compromised
and it wishes to move to a new certificate before it planned.
Adam
Eddy Nigg
> ^^^^ There's significant interest in this feature from chrome-security
> as well.
There is however a very limited benefit and would only prevent a
particular type of failure if at all. The enforcement for it would have
to be baked into the client software and adherence by CAs would have to
be required by policy. I don't see that happening at the moment,
specially because the benefit is fairly small for the hassle.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Adam Barth
> On 04/09/2011 01:52 AM, From Adam Barth:
>> as well.
>
> type of failure if at all. The enforcement for it would have to be baked
> into the client software and adherence by CAs would have to be required by
> policy. I don't see that happening at the moment, specially because the
> benefit is fairly small for the hassle.
I'm reasonably sure that it will happen in some form or another given
the amount of interest on the part of browser implementors and web
site operators.
There's no dependencies on the CAs, as far as I understand. Can you
explain what you think the CAs will need to adhere to?
Adam
Eddy Nigg
> There's no dependencies on the CAs, as far as I understand. Can you
> explain what you think the CAs will need to adhere to?
Probably we aren't talking about the same - I was referring to "CA
locking functionality in HSTS or via CAA". And you?
Adam Barth
> On 04/09/2011 09:36 PM, From Adam Barth:
>> explain what you think the CAs will need to adhere to?
>
> functionality in HSTS or via CAA". And you?
Yes. Certificate (or CA) pinning in HSTS is an agreement between a
web site and a browser. Certificate authorities aren't really
involved. In particular, CAs won't need to adhere to anything.
Adam
Eddy Nigg (StartCom Ltd.)
On 04/09/2011 10:32 PM, From Adam Barth:
> Yes. Certificate (or CA) pinning in HSTS is an agreement between a
> web site and a browser.
Excellent! Even though I assume that this still prevents only a
particular failure and probably should never be a substitute or shifting
of responsibilities by the CAs.
But as long that this is voluntarily and optionally for those
seeking/needing/wanting an added break, I think that's nice to have.
Regards
Signer: Eddy Nigg, COO/CTO
StartCom Ltd. <http://www.startcom.org>
XMPP: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Twitter: Follow Me <http://twitter.com/eddy_nigg>
Jean-Marc Desperrier
> The only requirement
> is that future certificate chains MUST include that certificate. That
> effectively gives you EV pinning,
I might not have been very clear by what I meant with EV pinning.
It was more EV *status* pinning, that is do not in the future allow the
connexion to be with a DV cert instead of an EV cert.
This in my opinion is more useful than the cert pinning you describe. I
think it's more useful to focus on an end goal, ensure this property
stays true, rather a specific technical characteristic, pin on this cert.
In this view, in addition to the EV status, it could be useful to pin
the certificate chain to some geographic localization. "I'm an American
company and I'll use American based CA and RA for my certificate. If the
next certificate you get has been issued from Tunisia (Ben Ali's
government used to have a governmental CA, included in Microsoft trust
store) or China, it'll be very suspicious". This transposes to letting
non-american companies decide they'll certainly never want to use a
certificate from America (one could think of the pirate bay or wikileaks).
The conspiracy http://kuix.de/conspiracy/ extension for Firefox will
already show this info.
> In addition to thinking about orderly transitions to new certificates
> (as you mention), there's also the case of disorderly transitions.
Yes, this shows that pinning to a specific certificate is an engineer's
idea, but not something that actually works.
Lets' be clear : CAs would love a solution where the clients are chained
to continue using their product and never change to something else,
"strictly for security reasons".
Gervase Markham
> In addition to thinking about orderly transitions to new certificates
> (as you mention), there's also the case of disorderly transitions.
> For example, what happens if the site's private key gets compromised
> and it wishes to move to a new certificate before it planned.
This is why it seems to me that certificate attribute locking, as
opposed to particular certificate locking, has to be the way to go.
The entire point of PKI, as opposed to models like SSH/TOFU, is that
it's not the particular certificate which matters, but the chain to the
point of trust. The aim of "locking" is to segment the trust landscape
so that a site can say "do not trust all X hundred CAs for my site,
trust only this one, or these two". They can then insulate themselves
from the possibility of a compromise elsewhere.
Pinning a particular certificate seems to meet this goal only imperfectly.
Gerv
Stephen Schultze
> - Implement subscription-based blocklisting of certs via update ping
> (remove need to ship patch)
Is there a bug for this? Would this permit blocklisting of CA certs or
just EE? Would it allow third parties to maintain and distribute such
blocklists?
> - CA locking functionality in HSTS or via CAA
I am not aware of a spec (yet) for HSTS to do this.
CAA (do-not-issue) is experimental track, and the draft is still pretty
rough.
DANE is standards track, and it anticipates this functionality in the
current draft section 2.3 -- cert type 2.
I suggest a DANE and/or HSTS approach.
Gervase Markham
> On 4/8/11 6:49 PM, Sid Stamm wrote:
>> - Implement subscription-based blocklisting of certs via update ping
>> (remove need to ship patch)
>
> Is there a bug for this?
Not that I know of; if there isn't, we need one.
> Would this permit blocklisting of CA certs or
> just EE?
I believe the plan is to allow either.
> Would it allow third parties to maintain and distribute such
> blocklists?
Hmm. Not unless you also want to maintain blocklists for addons and
graphics drivers as well, or for your users to lose that functionality.
(I guess you could download the Mozilla one and merge in your own list.)
>> - CA locking functionality in HSTS or via CAA
>
> I am not aware of a spec (yet) for HSTS to do this.
Indeed not. However, one would not be too tricky to write.
> CAA (do-not-issue) is experimental track, and the draft is still pretty
> rough.
>
> DANE is standards track, and it anticipates this functionality in the
> current draft section 2.3 -- cert type 2.
DANE does the same thing? I had not noticed that. What does Phil
Hallam-Baker say about the overlap?
Gerv
Stephen Schultze
that seems to have filtered out the first one I posted.)
On 4/8/11 6:49 PM, Sid Stamm wrote:
> - Implement subscription-based blocklisting of certs via update ping
> (remove need to ship patch)
Is there a bug for this? Would this permit blocklisting of CA certs or
just EE? Would it allow third parties to maintain and distribute such
blocklists?
> - CA locking functionality in HSTS or via CAA
I am not aware of a spec (yet) for HSTS to do this.
CAA (do-not-issue) is experimental track, and the draft is still pretty
rough.
DANE is standards track, and it anticipates this functionality in the
current draft section 2.3 -- cert type 2.
I suggest a DANE and/or HSTS approach.
Brian Smith
> On 09/04/11 18:05, Adam Barth wrote:
> > In addition to thinking about orderly transitions to new
> > certificates (as you mention), there's also the case of disorderly
> > transitions. For example, what happens if the site's private key
> > gets compromised and it wishes to move to a new certificate before
> > it planned.
>
> This is why it seems to me that certificate attribute locking, as
> opposed to particular certificate locking, has to be the way to go.
If you need to switch CAs immediately, then you had better have already purchased a backup EV cert, because it is unlikely that you will be able to get a new EV cert from a different CA in a reasonable time frame. In that case, you already know which CA you are using as a backup, so the website could lock its domain to both CAs' EV intermediate certs in advance.
If you have merely a "EV lock," then you are still trusting every CA with an EV root, and you will still have the choice of getting the backup cert in advance or dealing with downtime or operating the website in a comprised state.
> The aim of "locking" is to segment the trust landscape
> so that a site can say "do not trust all X hundred CAs for my site,
> trust only this one, or these two". They can then insulate themselves
> from the possibility of a compromise elsewhere.
>
> Pinning a particular certificate seems to meet this goal only
> imperfectly.
I mostly agree. But, a website may want to trade this flexibility for a greater protection against misbehavior of the one or two CAs they have chosen to do business with. Such a mechanism shouldn't require a website administrator to trust *any* CA more than necessary.
Cheers,
Brian
Stephen Schultze
>> Would it allow third parties to maintain and distribute such
>> blocklists?
>
> Hmm. Not unless you also want to maintain blocklists for addons and
> graphics drivers as well, or for your users to lose that functionality.
> (I guess you could download the Mozilla one and merge in your own list.)
I don't totally understand your point about addons and graphics drivers.
I guess I'm just not familiar enough with the codebase there.
In any case, the idea for user-maintained block lists would be to enable
something for CA (and Sub-CA) blocking akin to Adblock lists.
Knowledgeable super-users can make lists for security-conscious people
to subscribe to.
>>> - CA locking functionality in HSTS or via CAA
>>
>> I am not aware of a spec (yet) for HSTS to do this.
>
> Indeed not. However, one would not be too tricky to write.
>
>> CAA (do-not-issue) is experimental track, and the draft is still pretty
>> rough.
>>
>> DANE is standards track, and it anticipates this functionality in the
>> current draft section 2.3 -- cert type 2.
>
> DANE does the same thing? I had not noticed that. What does Phil
> Hallam-Baker say about the overlap?
The primary purpose of CAA is a communication from the domain owner to a
potentially issuing CA. PHB forked CAA when we told him that was out of
scope for DANE.
In addition to that core purpose, he has also included references to the
fact that "Relying Party Applications MAY enforce CAA issue restrictions
at their option, provided that the Relying Party Authorization set is
not empty." but admitted that, "The consequences of determining that a
certificate is not compatible with the specified CAA relying party
restrictions are outside the scope of this document." he hasn't
described any of the anticipated semantics for these records other than
reserving a bit for them. All of this, plus the fact that it is an
experimental draft, make me believe that it is not optimal for building
current functionality on top of.
http://tools.ietf.org/html/draft-hallambaker-donotissue
Members of DANE have told PHB and Ben that they support his core goal
but that the client validation stuff is overlapping with the DANE work
and probably best pursued there.
http://www.ietf.org/mail-archive/web/dane/current/msg01316.html
DANE, on the other hand, is intended primarily for communication from
domain owners to relying party applications, and the group is working
through many of the relevant issues. The difference between delivering
an EE cert and a CA cert is minimal.
Steve
Brian Smith
> On 12/04/11 14:22, Stephen Schultze wrote:
> >> - Implement subscription-based blocklisting of certs via update
> >> ping
> >> (remove need to ship patch)
> >
> > Is there a bug for this?
See https://bugzilla.mozilla.org/show_bug.cgi?id=647868
> > Would it allow third parties to maintain and distribute such
> > blocklists?
Kai has written a patch to add some infrastructure for extensions to implement their own similar mechanisms. You may be able to override the built-in mechanism's server's URL with another one with some pref hacking, but that would not be "supported" but instead something to use for testing purposes.
- Brian
Brian Smith
> On 12/04/11 14:22, Stephen Schultze wrote:
> > On 4/8/11 6:49 PM, Sid Stamm wrote:
> >
> > I am not aware of a spec (yet) for HSTS to do this.
>
> Indeed not. However, one would not be too tricky to write.
Right. The main motivation for supporting this in HSTS or a HSTS-like mechanism is to get something that is immediately usable (not requiring DNSSEC deployment, not requiring TLS implementation changes, not requiring CA participation), if imperfect (like HSTS itself).
- Brian
Stephen Schultze
> Gervase Markham wrote:
>> On 12/04/11 14:22, Stephen Schultze wrote:
>>> On 4/8/11 6:49 PM, Sid Stamm wrote:
>>>> - Implement subscription-based blocklisting of certs via
>>>> update ping (remove need to ship patch)
>>>
>>> blocklists?
>
> Kai has written a patch to add some infrastructure for extensions to
> implement their own similar mechanisms. You may be able to override
> the built-in mechanism's server's URL with another one with some pref
> hacking, but that would not be "supported" but instead something to
> use for testing purposes.
Is there somewhere I can read about this? I don't understand what you
mean by "similar mechanisms." Is it a general structure for fetching
updates of blocklists and doing arbitrary things with them, or something
else?
Brian Smith
See https://bugzilla.mozilla.org/show_bug.cgi?id=644640.
Basically, it is a generic hool for extensions to influence the application's decision on whether or not to trust a certificate.
- Brian
Zack Weinberg
Counterpoint: If the attacker is (or colludes with) a rogue CA, they are
in a position to make the *entire contents* of the certificate be
whatever they want. They can forge EV status, they can forge the O=,
they can forge the serial number, they can make it appear to be exactly
the same as the legitimate certificate they're spoofing. If the rogue
CA is the *same* as the CA that signed the legitimate certificate (which
is a real possibility in "the attacker is a nation-state" scenarios)
they can even make the signing key match.
The only thing that *can't* match the legitimate certificate is the
public key itself, because the attacker doesn't get anything for their
trouble if they don't change the keypair.
Therefore, I don't see attribute locking as providing any real security
benefits. Pubkey locking (or, equivalently, cert locking), on the other
hand, *does*, and CA locking also helps if you don't have to worry about
*your* CA being suborned (which should be the common case even with
state surveillance expanding as fast as it is).
Worries about disorderly transitions, needing to change CAs, etc., seem
to me to be adequately addressed by short-lived records in DNS - it's
not any worse than needing to change IP addresses, anyway.
zw
Sid Stamm
I think Brian is referring to this:
https://bugzilla.mozilla.org/show_bug.cgi?id=644640
.... which would allow add-ons to change what certs are considered
"valid" and what are not.
-Sid
Gervase Markham
> I don't totally understand your point about addons and graphics drivers.
> I guess I'm just not familiar enough with the codebase there.
Sorry. What I meant was, the current plan is to leverage the existing
system where Firefox pings us every day to download a blacklist of addon
UIDs and graphics drivers. So if you wanted to implement your own
system, you would need to change the URL pinged, which means you would
also need to provide those blacklists (or deprive your users of them).
> reserving a bit for them. All of this, plus the fact that it is an
> experimental draft, make me believe that it is not optimal for building
> current functionality on top of.
Then again, as I understand it, an RR type has been allocated for CAA
experimentation, whereas DANE is quite a way from having their system
and wire formats locked down. Is that right?
Gerv
Gervase Markham
> On 4/13/11 2:02 PM, Brian Smith wrote:
>> Gervase Markham wrote:
>>> On 12/04/11 14:22, Stephen Schultze wrote:
>>>> On 4/8/11 6:49 PM, Sid Stamm wrote:
>>>>> - Implement subscription-based blocklisting of certs via
>>>>> update ping (remove need to ship patch)
>>>>
>>>> Would it allow third parties to maintain and distribute such
>>>> blocklists?
>>
>> Kai has written a patch to add some infrastructure for extensions to
>> implement their own similar mechanisms. You may be able to override
>> the built-in mechanism's server's URL with another one with some pref
>> hacking, but that would not be "supported" but instead something to
>> use for testing purposes.
>
> Is there somewhere I can read about this? I don't understand what you
> mean by "similar mechanisms."
Kai's patch allows extensions to hook into the certificate trust/untrust
system, and make decisions. So you could do that based on a blocklist if
you like.
> Is it a general structure for fetching
> updates of blocklists and doing arbitrary things with them, or something
> else?
I'm sorry; we have got two ideas confused here.
I was making the point that we plan to extend Firefox's existing
blacklist system, downloaded daily, to have a category for certs.
Brian was making the point that you could use Kai's hook to write an
addon which did its own blacklist downloading, using whatever server or
format you wanted, and disallowed the certs it heard about.
Gerv
Jean-Marc Desperrier
> Counterpoint: If the attacker is (or colludes with) a rogue CA, they are
> in a position to make the *entire contents* of the certificate be
> whatever they want. They can forge EV status
Not really. EV status depends on the root certificate. If we'd lock on
something else, we'd made sure that it's based on the CA's values,
rather than the one of the issued certificates. The key that sign the CA
certificate ought to be off-line and much harder to compromise.
Jean-Marc Desperrier
> a real possibility in "the attacker is a nation-state" scenarios
*Public* PKI as it is implemented in the browsers does *not* protect
against nation-state attack scenario. It just can't.
A nation-state attack scenario means, amongst other things, the attacker
can get a perfectly valid ID that in fact is false (think Dubai Hamas
assassination and the Bristish passports). No commercial CA will be able
to do anything against that.
If that's the scenario you want to fight, and I'm not saying they aren't
valid reason to aim for it, you need either not use PKI at all, or use
your own private one with your own rules.
But it's not a useful purpose of a general usage browser to try to do
anything about that.
Zack Weinberg
I've been assuming that it is only marginally harder to compromise an EV
signing key than it is to compromise a DV one. Under the circumstances,
I don't think that's a bad assumption.
> *Public* PKI as it is implemented in the browsers does *not* protect
> against nation-state attack scenario. It just can't.
> A nation-state attack scenario means, amongst other things, the attacker
> can get a perfectly valid ID that in fact is false (think Dubai Hamas
> assassination and the Bristish passports). No commercial CA will be able
> to do anything against that.
Cert-locking *does* defend against the nation-state scenario: it doesn't
matter what the secret police cozened out of their friends at some CA,
because you already have your keypair and it's declared as the only
correct one, so that's the only one the browser will accept.
[It doesn't defend against the case where the secret police get *your*
CA to *revoke* your certificate, but they can't do that if they don't
want you to notice. It also doesn't defend against the case where the
secret police can lean on the people who sign any of the zones between
you and the DNS root -- which is why, long term, I want to be looking
for solutions that don't rely on third party signatures at all. But
there is no such solution on the table just now, and we mustn't throw
away real short-term security improvements in a quest for long-term ideals.]
zw
Nelson B
> Hi everybody.
Everybody?
Why isn't this discussion at least cross posted to dev.tech.crypto
where the NSS people hang out?
> After the few meetings and a couple of hours of discussion in the last
> two days, we've made a short list of desired upgrades for NSS/PSM for
> the near term. This message should hopefully serve as a summary of the
> technical bits that -- based on the discussions -- seemed most urgent.
Who "we", white man? Seriously, we are the "we" who had these meetings?
I can tell you there are NSS developers who never heard about this until now.
Gervase Markham
would be welcome:
On 08/04/11 23:49, Sid Stamm wrote:
> Bucket A:
> - Move to libpkix for all cert validation (bug 479393)
The code is now checked in; bug 651246 tracks flipping the necessary
pref. Brian Smith is working on the dependencies of this bug.
> - Complete active distrust in NSS (bug 470994)
I thought Bob was working on this, including some preliminary cleanup of
NSS flag names, but I haven't seen anything more recently. Bob?
> - Implement callbacks to augment validation checking (bug 644640)
It has been decided not to work further on this at the present time,
because it is too hard to design an API which meets sufficient numbers
of use cases. Those wanting to do trust experiments will need to ship
their own custom builds for now.
> - Implement subscription-based blocklisting of certs via update ping
> (remove need to ship patch)
Is there a bug for this?
> Bucket B:
> - Implement OCSP Stapling (bug 360420)
Kai produced a WIP patch for this on 10th April.
> - Implement date-based revocation (distrust certs after specific date)
This is bug 643982 - no recent progress.
> - CA locking functionality in HSTS or via CAA
Debate continues as to the best mechanism to do this.
> Bucket C:
> - Disable cert overrides for *very old* expired certs (might not be in
> any CRLs anymore)
I don't know what the status is here.
Gerv
Gervase Markham
> Everybody?
>
> Why isn't this discussion at least cross posted to dev.tech.crypto
> where the NSS people hang out?
My apologies. It was posted both in mozilla.dev.security and
mozilla.dev.security.policy, which is where discussion has been going on
regarding the recent CA security breaches.
There was at least one NSS developer (Bob Relyea) at the meeting, and
Kai was there too.
The meeting was also trailled at the open meeting we had the previous
day, which was widely publicised, and which had representation from
several companies and CAs. We tried to get dial-in available bit it
didn't work in the chosen room; however, no-one reported not being able
to attend for this reason.
>> After the few meetings and a couple of hours of discussion in the last
>> two days, we've made a short list of desired upgrades for NSS/PSM for
>> the near term. This message should hopefully serve as a summary of the
>> technical bits that -- based on the discussions -- seemed most urgent.
>
> Who "we", white man? Seriously, we are the "we" who had these meetings?
Meeting attendees I can remember were:
Sid Stamm
Brian Smith
Lucas Adamski
Chris Hofmann
Kai Engert
Bob Relyea
Gervase Markham
I think there were several other people there, but my memory is failing me.
> I can tell you there are NSS developers who never heard about this until now.
I apologise if we have under-communicated.
Gerv