On Mon, Mar 16, 2020 at 12:11:57PM -0700, Chris Kemmerer via
dev-security-policy wrote:
> On Wednesday, March 11, 2020 at 5:41:00 PM UTC-5, Matt Palmer wrote:
> > On Wed, Mar 11, 2020 at 10:46:05AM -0700, Chris Kemmerer via
> > dev-security-policy wrote:
> > > On Tuesday, March 10, 2020 at 8:44:49 PM UTC-5, Matt Palmer wrote:
> > > > On Tue, Mar 10, 2020 at 01:48:49PM -0700, Chris Kemmerer via
> > > > dev-security-policy wrote:
> > > For what it's worth, we believe that the current language in the BRs could
> > > be less ambiguous as far as the Debian weak keys are concerned. For
> > > example, it seems that the community's expectations are for CAs to detect
> > > and block weak Debian keys generated by vulnerable RNG using OpenSSL in
> > > popular architectures.
> >
> > The problem with using the argument that "the BRs are ambiguous" to try and
> > defend a breach of them is that there are always potential ambiguities in
> > all language -- in many ways, "ambiguity is in the eye of the beholder"
> > ("ambiguer"?). My understanding of the consensus from past discussions on
> > this list is that if a CA believes there is an ambiguity in the BRs, the
> > correct action is to raise that in the CA/B Forum *before* they fall foul of
> > it.
> >
> > CAs should be reading the BRs, as I understand it, in a "defensive" mode,
> > looking for requirements that could be read multiple ways, and when they are
> > found, the CA needs to ensure either that they are complying with the
> > strictest possible reading, or else bringing the ambiguity to the attention
> > of the CA/B Forum and suggesting less ambiguous wording.
> >
> > At any rate, it would be helpful to know what, precisely, SSL.com's
> > understanding of this requirement of the BRs prior to the commencement of
> > this incident. Can you share this with us? Presumably SSL.com did a
> > careful analysis of all aspects of the BRs, and came to a conclusion as to
> > precisely what was considered "compliant". With regards to this
> > requirement, what was SSL.com's position as to what was necessary to be
> > compliant with this aspect of the BRs?
>
> We have already described our understanding of the expectations expressed
> in BR 6.1.1.3 and the steps we took to comply with it.
Sorry, I must have missed the description of SSL.com's understanding. Could
you quote or reference it here, for clarity?
> Our implementation did not meet these expectations, as it was missing
> direct checks of keys matching the "openssl-blacklist" package.
> Immediately upon our coming to this understanding,
This is SSL.com's post-incident understanding; what I believe is important
to also know is SSL.com's *pre*-incident understanding of the BR
requirements.
> > > That could be added in the BRs:
> > >
> > > Change:
> > > "The CA SHALL reject a certificate request if the requested Public Key
> > > does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if
> > > it has a known weak Private Key (such as a Debian weak key, see
> > > http://wiki.debian.org/SSLkeys)"
> > >
> > > to something like:
> > > "The CA SHALL reject a certificate request if the requested Public Key
> > > does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if
> > > it has a known weak Private Key using, as a minimum set the Debian weak
> > > keys produced by OpenSSL in i386 and x64 architectures (see
> > > http://wiki.debian.org/SSLkeys)"
> >
> > It would appear that SSL.com is a member in good standing of the CA/B
> > Forum.
> > Is there any intention on the part of SSL.com to propose this change as a
> > ballot? While you're at it, if you could include a fix for the issue
> > described in https://github.com/cabforum/documents/issues/164, that would be
> > appreciated, since it is the same sentences that need modification, and for
> > much the same reasons.
>
> Yes, this is reasonable, and we treated such key as compromised, revoking
> it within 24 hours.
>
> We would support a ballot that makes this clear. We also monitor the
> discussion in https://github.com/cabforum/documents/issues/164.
As Ryan mentioned, "we would support a ballot" is not the same as "we intend
to propose a ballot". Thank you for clarifying that SSL.com intends to
propse a ballot in your reply to Ryan.
> > > Then, it would be clear that all CAs would need to block "at least" the
> > > vulnerable keys produced by OpenSSL and could add other keys produced by
> > > OpenSSH or other applications if they wanted a "more complete" list.
> >
> > Well, you're still missing the rnd/nornd/noreadrnd variations, and there's
> > no specification as to what key sizes are considered the bare minimum.
>
> We mention these variations in bug 1620772, but thank you for repeating it
> here for completeness.
>
> For the record, this fact (“there's no specification as to what key sizes
> are considered the bare minimum”) is exactly our point too.
I think you misunderstood my point here. I was making an observation that
your proposed improved language was not comprehensive, and would allow CAs
in the future to continue to argue that the BRs were ambiguous when *they*
issued a certificate with a known-to-the-openssl-blacklist-package weak key.
It was an attempt to show that drafting ambiguity-free requirements is
*hard*, to emphasise that reading the BRs in a "what's the bare minimum we
can possibly get away with" mindset is a dangerous path to tread.
> The BRs allow specific RSA key sizes.
I can't find anything in the BRs that mandates specific RSA public modulus
lengths. It defines a *minimum* length, to provide a reasonable security
level baseline, and most CAs impose maximum length (because, as I understand
it, 1,000,000 bit modulii tend to give HSMs indigestion), but I can't find
an explicit list of specific key sizes anywhere. Could you provide the
section number that describes which specific RSA key sizes are allowed?
> > > > > This information was disclosed on 2020-03-07 to the person that
> > > > > submitted
> > > > > the Certificate Problem Report.
> > > >
> > > > I don't see anything from SSL.com that looks relevant in my inbox, but
> > > > it's
> > > > not an important point, just thought I'd mention it in passing.
> > >
> > > For the record, we replied to [email protected] at 2020-03-07 8:41 PM
> > > (UTC)
> > > Email subject: "Problem Report for certificate(s) with compromised
> > > private key"
> > > Can you please confirm?
> > > We did disclose the source of our weak keys in that email.
> >
> > Unfortunately that's the default subject line I use on my problem reports,
> > so it's not as helpful as it might otherwise be. Looking through recent
> > correspondence, though, I'm certainly not finding anything. If you've got a
> > message ID, or even better the queue ID that my MTA would have responded
> > with when it accepted the message (which could be obtained from your MTA's
> > logs), that'd help me track down what happened to it. At any rate, there's
> > no delivery attempts at *all* in my mail logs between 20:37:19 and 21:03:30
> > on 2020-03-07, so it looks like it got in the post to at least some degree.
>
> The reply was submitted to the MTA at 2020-03-07 04:04 UTC. Apologies
> that the timezone conversion was incorrect. The ticket number was
> QGI-680-16751.
Still nothing in my MTA's logs for anywhere around that time. Would that
ticket number have been in the message subject? I log all subject lines,
and there's no incidence of that string in my logs for that week. As I said
before, either the message ID, or the queue ID that my MTA includes in the
`250` response to the DATA command, would be the best information to help me
track down the message.
> > > > > The above practices comply with our CP/CPS, version 1.8, section
> > > > > 6.1.1.2,
> > > > > which states:
> > > > >
> > > > > "SSL.com shall reject a certificate request if the request has a known
> > > > > weak Private Key".
> > > >
> > > > Hmm, "known" is doing a lot of work in that sentence. Known to *whom*
> > > > is
> > > > the important, but unanswered, question.
> >
> > [snip]
> >
> > > This language was mainly taken from the Baseline Requirements.
> >
> > Sure, but SSL.com presumably came to some understanding as to what that
> > sentence meant at the time it was included in SSL.com's CPS, given that the
> > organisation was committing to do it. I think it would be valuable to know
> > what that understanding was, if for no other reason than so that Mozilla can
> > say, in the next CA communication, "if you think that "known weak Private
> > Key" means "known to <X>, be advised that that that is not an appropriate
> > interpretation, and you'll want to get onto that."
>
> We have responded as to how we interpreted and implemented this requirement.
Again, whilst you have explained SSL.com's implementation of this part of
its CPS, I don't feel that SSL.com's interpretation has been explained.
Specifically, the intended meaning of the word "known" in the phrase "known
weak Private Key" in the SSL.com CPS still, as far as I can see, has not
been explained.
> > Further, a point-in-time publication of any list of keys would not be
> > particularly useful, as new private keys are *regularly* being disclosed,
> > and thus any list would very quickly be out-of-date. Even if the published
> > list were regularly augmented with new entries, history has shown that
> > people are far too keen on downloading a list once, stuffing into their (in
> > this case) CA software, and saying "job done!", and thus they lull
> > themselves into a false sense of security.
> >
> > I've seen this happen in many contexts over the years, such as in network
> > operations -- bogon lists get loaded into routers and firewalls, they don't
> > get updated, and it causes problems everywhere and forever. I'm not going
> > to be party to creating yet another instance of the same problem with
> > private keys.
>
> Once a private key has been compromised, it's compromised. It's an
> "add-only" database. Therefore, we believe it would be a large
> contribution to this community if the *public keys* of compromised private
> keys (and reason of compromise for verification) were available for
> download. CAs could periodically synchronize their local blacklists with
> new entries of this blacklist. This is one way we see to deal with the
> interoperability issue of different implementations for weak/compromised
> key detection.
Is SSL.com willing to come to the party on this "large contribution", or are
they expecting volunteers to do all the work for them for free?
> We would welcome discussion with security researchers regarding
> collecting, documenting and disclosing such weak/compromised public keys
> as a means of improving weak/compromised key detection by CAs and other
> participants in the PKI community.
I think I compromise a representative portion of the set of "security
researchers" working on disclosed private keys. Here I am. Discuss away.
- Matt
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
