[Servercert-wg] Compromised/Weak Keys Ballot Proposal

Wed Apr 10 18:51:41 UTC 2024

Hi Clint,

I think my latest proposal [1] is essentially what you are proposing in
option #2, the only difference being that we would add repositories
containing weak keys to https://cabforum.org/resources/tools/ (and we can
do that without a ballot). If you are instead proposing that we require CAs
to check for a specified weak keys contained in one or more repositories,
then that is similar to Aaron's proposal except that I understand you want
to require CAs to also check for weak keys even if they sign non-standard
key sizes that are not included in the repository of weak keys.

The more I think about the two approaches, the more I prefer my current
proposal [1] that does not require CAs to check for specific keys found in
one or more repositories. The reason is that I believe CAs already have
Debian weak key checks in place and would likely prefer not to have to
change their systems to use different logic/data to meet the same
requirement as before.

Thanks,

Wayne

[1] https://github.com/wthayer/servercert/pull/1/files

On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson <clintw at apple.com> wrote:

> Hi Wayne,
>
> I think this does seem like it could be a tractable solution, however I’d
> like to understand why one of the proposals I’ve brought up a couple times
> on the calls isn’t also a suitable option. From what I can gather, they’re
> nearly identical in practical impact, but one provides a much more defined
> boundary for relying parties.
>
> Option 1:
> The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys
> for the following key sizes (representing those most commonly issued
> against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs
> stipulate that CAs must not issue certificates containing keys in this
> repository.
>
> Option 2:
> The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys
> for the following key sizes (representing those most commonly issued
> against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs
> stipulate that CAs must not issue certificates containing weak keys, with a
> pointer to the repository of the most common key sizes of Debian Weak keys
> among other similar/relevant pointers for other vulnerabilities.
>
> The reason these 2 proposals are so nearly identical in practice is that
> there are only a very tiny number of certificates issued against key sizes
> that are not RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By
> my count, somewhere around 80 certificates out of roughly 750 million
> (though I really only took a quick glance, so perhaps this is off to an
> extent… but probably not by huge quantities).
>
> Under Option 2, if a CA wants to allow for Certificate requests containing
> a key size other than these 7, they’re fully free to do so; they must
> merely ensure the key is not a Debian Weak key. For every other CA, they
> can limit the accepted key sizes to those in the repository and the result
> is functionally the same as Option 1, but without the possibility of
> “certificates can be issued that are weak and CAs are under no obligation
> to prevent that if it’s not one of 7 key sizes”.
>
> Concretely, is there a reason Option 2 is intractable for CAs? If so, I
> would greatly appreciate help understanding how that approach meaningfully
> differs from Option 1.
>
> Thanks,
> -Clint
>
> On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> > * Aaron Gable commented in the PR with a suggestion that we require CAs
> to reject any key found in Hanno Bock's repository at
> https://github.com/badkeys/debianopenssl. This includes RSA
> 1024/2048/3072/4096 and EC P256/P384 keys.
>
> Some of the EC key files in Hanno's repository have ASN.1 encoding issues
> (see
> https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html);
> whereas the equivalent files in
> https://github.com/CVE-2008-0166/private_keys are correctly encoded.
>
> > * Roman Fischer suggested that we limit the requirement to check Debian
> weak keys only with sizes up to RSA 4096 under the logic that no one would
> “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian
> Weak keys
>
> FWIW, https://github.com/CVE-2008-0166/private_keys already has all of
> the possible 8192-bit RSA Debian weak keys.
>
> ------------------------------
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org>
> *Sent:* 05 April 2024 23:47
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> Two new alternatives have been proposed in addition to the one I proposed
> below:
>
> * Aaron Gable commented in the PR with a suggestion that we require CAs to
> reject any key found in Hanno Bock's repository at
> https://github.com/badkeys/debianopenssl. This includes RSA
> 1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a
> clone in the CAB Forum GitHub org (or some other source of the actual
> generated weak keys) but that's a detail we can work out if others like
> this approach.
> * Roman Fischer suggested that we limit the requirement to check Debian
> weak keys only with sizes up to RSA 4096 under the logic that no one would
> “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian
> Weak keys
>
> Each of these methods has the benefit of adding clarity to the Debian
> requirement rather than just maintaining the existing language, but they
> also [arguably] allow CAs to issue certs containing abnormally sized Debian
> weak keys.
>
> I would like to hear from other members (especially Apple) if you prefer
> or object to either of these alternatives?
>
> Thanks,
>
> Wayne
>
> On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> There was further discussion of this ballot proposal on today's
> teleconference. It was suggested that rather than omitting any reference to
> Debian weak keys, the ballot should retain the current language.
> Unfortunately, the ballot restructures the language in such a way that this
> is challenging. My new proposal is that TLS BR Section 6.1.1.3(5) be
> updated to read as follows (
> https://github.com/wthayer/servercert/pull/1/files):
> =====
> 5. The Public Key corresponds to an industry-demonstrated weak Private
> Key. For requests submitted on or after November 15, 2024, at least the
> following precautions SHALL be implemented:
>     1. The CA SHALL reject Debian weak keys (
> https://wiki.debian.org/SSLkeys).
>     2. In the case of ROCA vulnerability, the CA SHALL reject keys
> identified by the tools available at https://github.com/crocs-muni/roca or
> equivalent.
>     3. In the case of Close Primes vulnerability (
> https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which
> can be factored within 100 rounds using Fermat’s factorization method.
>
>     Suggested tools for checking for weak keys can be found here:
> https://cabforum.org/resources/tools/
> =====
> I would greatly appreciate feedback from any member that finds this
> language unacceptable, or that has suggestions to improve it.
>
> Thanks,
>
> Wayne
>
>
> On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> On yesterday's SCWG teleconference, Mads suggested that a way forward
> would be to leave the existing requirements in place for Debian weak keys.
> I've interpreted that to mean that we would just remove references to
> Debian, resulting in this:
> https://github.com/wthayer/servercert/pull/1/files
>
> I'm not satisfied by this approach because it doesn't achieve the clarity
> intended to result from the original weak keys ballot and will seemingly
> result in CAs continuing to have varying interpretations of the specific
> requirements for rejecting Debian weak keys, but perhaps this is the best
> we can all agree to.
>
> What  do others think? Should we proceed with this approach?
>
> Thanks,
>
> Wayne
>
> On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
> FWIW, I think in the recent years, it was mostly security researchers that
> attempted to request certificates with Debian weak keys to test if a CA was
> properly blocking them.
>
> If an Applicant uses an outdated OS that generates weak keys, imagine the
> actual web server or other software that runs on that server, putting
> Relying Parties at risk. CAs don't have control over that but they could
> have control over a common set of weak keys using common
> parameters/algorithms which could be enforced by all CAs.
>
> Dimitris.
>
> On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
>
> Hi Clint,
>
> Thank you for your response. Unfortunately, it leads me to the conclusion
> that there is not a path forward and we're stuck with the status quo.
> Having said that, I'll reply to a few of your points below and encourage
> others to do the same if there is a desire to move forward with an update
> to our weak keys requirements.
>
> On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson <clintw at apple.com> wrote:
>
> Hi Wayne,
>
> Thank you for carrying this work item forward. I have a few concerns
> regarding the proposed removal of Debian weak key checking, outlined below.
>
> I don’t believe there has been sufficient explanation or data presented to
> justify the removal of the requirement to check for Debian weak keys. It
> seems to me there are feasible methods for CAs to continue performing this
> check. Similar to what Martijn has pointed out, the reasoning provided is
> lacking (hasty generalization, fallacy of composition, etc.).
>
>
> The argument that I find compelling is that any system capable of
> generating a Debian weak key in 2024 is also riddled with a decade of
> vulnerabilities, so preventing the use of said weak key in a certificate is
> security theater. In what scenario do you envision the rejection of a
> Debian weak key having a meaningful impact on the security of a service
> that relies on it? It's just not obvious to me that these checks continue
> to provide any practical value at this point in time.
>
>
> I don’t believe a compromise where Debian weak keys only need be checked
> for specific key sizes addresses the core issue, unless tied together with
> a restriction from accepting key sizes which are not included in such a
> list (which I do see as reasonable and something I’m under the impression
> is already being done by some CAs).
>
>
> My understanding is that the objections some CAs had to the original
> ballot was the requirement to maintain a sizable database of Debian weak
> keys for every key size they support. Limiting the requirement to the most
> popular key sizes would resolve that issue and be more inline with my
> understanding of some current practices. This approach would also greatly
> reduce the threat of the accidental use of a Debian weak key.
>
>
> The removal of this check seems to shift a burden currently placed on CAs
> to a risk (long assumed resolved) for Relying Parties and Subscribers. From
> my reading of the ballot, the requirement that a CA revoke Certificates
> with Debian weak keys remains in effect, serving only to remove the
> pre-issuance “blocking” requirement, but retaining an expectation that
> certificates are checked post-issuance based on the CA’s awareness of this
> method of compromising a Private Key; this generally seems a significantly
> worse experience for Subscribers. Have I missed something regarding the
> intent of the changes in this regard?
>
>
> This is a great point. It makes no sense to allow a CA to issue a cert
> that is then immediately subject to a revocation requirement. I am open to
> either exempting Debian weak keys from BR 4.9.1.1(4) or for CAs to be
> required to revoke a certificate containing a Debian weak key only if they
> are "made aware" using the mechanism specified in 4.9.3.
>
> Thanks,
>
> Wayne
>
>
> There have been incidents involving certificates issued to Debian weak
> keys in recent years; some CAs have indicated that they don’t receive
> Debian weak keys in requests, but evidence exists to the contrary for the
> ecosystem as a whole.
>
> Thank you!
> -Clint
>
>
> _______________________________________________
> Servercert-wg mailing listServercert-wg at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240410/ca623c84/attachment-0001.html>