On Tue, 4 Dec 2018 01:39:05 +0100
Jakob Bohm via dev-security-policy
<[email protected]> wrote:
> A few clarifications below
> Interesting. What is that hole?
I had assumed that you weren't aware that you could just use these
systems as designed. Your follow-up clarifies that you believe doing
this is unsafe. I will endeavour to explain why you're mistaken.
But also I specifically endorse _learning by doing_. Experiment for
yourself with how easy it is to achieve auto-renewal with something like
ACME, try to request renewals against a site that's configured for
"stateless renewal" but with a new ("bad guy") key instead of your real
ACME account keys.
> It certainly needs the ability to change private keys (as reusing
> private keys for new certificates is bad practice and shouldn't be
> automated).
In which good practice document can I read that private keys should be
replaced earlier than their ordinary lifetime if new certificates are
minted during that lifetime? Does this document explain how its authors
imagine the new certificate introduces a novel risk?
[ This seems like breakthrough work to me, it implies a previously
unimagined weakness in, at least, RSA ]
You must understand that bad guys can, if they wish, construct an
unlimited number of new certificates corresponding to an existing key,
silently. Does this too introduce an unacceptable risk ? If not, why is
the risk introduced if a trusted third party mints one or more further
certificates ?
No, I think the problem here is with your imaginary "bad practice".
You have muddled the lifetime of the certificate (which relates to the
decay in assurance of subject information validated and to other
considerations) with the lifetime of the keys, see below.
> By definition, the strength of public keys, especially TLS RSA
> signing keys used with PFS suites, involves a security tradeoff
> between the time that attackers have to break/factor the public key
> and the slowness of handling TLS connections with current generation
> standard hardware and software.
This is true.
> The current WebPKI/BR tradeoff/compromise is set at 2048 bit keys
> valid for about 24 months.
Nope. The limit of 825 days (not "about 24 months") is for leaf
certificate lifetime, not for keys. It's shorter than it once was not
out of concern about bad guys breaking 2048-bit RSA but because of
concern about algorithmic agility and the lifetime of subject
information validation, mostly the former.
Subscribers are _very_ strongly urged to choose shorter, not longer
lifetimes, again not because we're worried about 2048-bit RSA (you will
notice there's no exemption for 4096-bit keys) but because of agility
and validation.
But choosing new keys every time you get a new certificate is
purely a mechanical convenience of scheduling, not a technical necessity
- like a fellow who schedules an appointment at the barber each time he
receives a telephone bill, the one thing has nothing to do with the
other.
> It requires write access to the private keys, even if the operators
> might not need to see those keys, many real world systems don't allow
> granting "install new private key" permission without "see new
> private key" permission and "choose arbitrary private key" permission.
>
> Also, many real world systems don't allow installing a new
> certificate for an existing key without reinstalling the matching
> private key, simply because that's the interface.
>
> Traditional military encryption systems are built without these
> limitations, but civilian systems are often not.
Nevertheless.
I'm sure there's a system out there somewhere which requires you to
provide certificates on a 3.5" floppy disk. But that doesn't mean
issuing certificates can reasonably be said to require a 3.5" floppy
disk, it's just those particular systems.
> This is why good CAs send out reminder e-mails in advance. And why
> one should avoid CAs that use that contact point for infinite spam
> about new services.
They do say that insanity consists of doing the same thing over and
over and expecting different results.
> The scenario is "Bad guy requests new cert, CA properly challenges
> good guy at good guy address, good guy responds positively without
> reference to old good guy CSR, CA issues for bad guy CSR, bad guy
> grabs new cert from anywhere and matches to bad guy private key,
> bad guy does actual attack".
You wrote this in response to me explaining exactly why this scenario
won't work in ACME (or any system which wasn't designed by idiots -
though having read their patent filings the commercial CAs on the whole
may be taken as idiots to my understanding)
I did make one error though, in using the word "signature" when this
data is not a cryptographic signature, but rather a "JWK Thumbprint".
When "good guy responds positively" that positive response includes
a Thumbprint corresponding to their ACME public key. When they're
requesting issuance this works fine because they use their ACME keys
for their requests. But when a bad guy requests issuance it won't work
because the bad guy does not know that ACME private account key. They
can choose their own of course, but that won't match the Thumbprint on
the "positive response" and so the request fails.
> This would only work if the existing CA challenge can be re-used or
> there is no CA chosen challenge in the protocol. I have yet to look
> at http-01 as it doesn't fit my own usage scenarios.
Computers are programmable :D
Specifically in this case you:
1. Calculate your Thumbprint (off-line if appropriate) and make a note
of it.
2. Write a "program" (actually one configuration line for popular web
servers) to respond to all ACME challenges by playing back the random
challenge text with the Thumbprint appended as described in the ACME
protocol.
Nick.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
