Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

[Richard Barnes <[e-mail]>]

On Wed, Aug 12, 2015 at 10:30 PM, Eric Mill <[e-mail]> wrote:
>> That seems like a great way to simplify the protocol.  On the other
>> hand, Jacob's /.well-known/certificate/acme-account-keys.json idea is
>> also quite nice.
>
> This is only tangentially on-topic, but since the idea's been reinforced,
> just a note that some deployment setups will find it challenging to deploy
> and maintain special content at HTTP URIs that aren't part of the app's
> business logic. I'm thinking of platform-as-a-service hosts like Heroku or
> Cloud Foundry, which map hostnames entirely to "apps" (often with a code
> repository as the sole content source for URIs).
>
> Right now, /.well-known is only used for the Simple HTTP validation
> mechanism, where the ability to put special metadata at HTTP URIs within the
> validated hostname is already a prerequisite. Making that ability a
> requirement for the overall ACME protocol would add friction for a class of
> users.

Different environments are going to be able to do different
challenges.  That's why it's important to have multiple of them.

Just to pick two examples off the top of my head, Cloudflare typically
controls DNS, so DNS-based challenges will be easy for them.  Akamai
typically doesn't, so they might want to do an HTTP-based challenge.



>
> -- Eric
>
> On Thu, Aug 13, 2015 at 1:21 AM, Richard Barnes <[e-mail]> wrote:
>>
>> On Wed, Aug 12, 2015 at 4:04 PM, Andrew Ayer <[e-mail]> wrote:
>> > On Tue, 11 Aug 2015 22:52:05 -0700
>> > Richard Barnes <[e-mail]> wrote:
>> >
>> >> I'm not 100% sure I agree that there are non-trivial cases where RSA
>> >> allows one to find a key that will verify a given (message, signature)
>> >> pair.  (I would note, however, that you don't even need to find the
>> >> modular inverse d of e -- you just need n and e such that s^e == m mod
>> >> n.)  It's even less clear for ECDSA.  I'm not sure we even need to get
>> >> a clear answer to that question, though.  There are protocol ways to
>> >> hack around it, as you suggest.
>> >
>> > Thanks to Trevor Perrin, I now know that this attack is called
>> > "duplicate-signature key selection," and found a paper which presents
>> > a general way to construct a non-trivial RSA key (pages 4-5):
>> >
>> > http://eprint.iacr.org/2011/343
>> >
>> > It also presents an attack with ECDSA, though it depends on the
>> > attacker picking their own base point, and I believe that the
>> > commonly-used curves (P-256, P-384, and so on) specify a fixed base
>> > point.
>>
>> Nice find!  (Thanks, Trevor!)
>>
>> I would note, though that in practice, e=65537 pretty much always, and
>> the attack would almost never produce that value.  So this could still
>> be prevented by checks on account public keys.
>>
>> Still doesn't change the conclusion, though :)
>>
>> --Richard
>>
>>
>> >
>> >> I think you're on the right track that we really should just not use
>> >> signatures here.  I had added those in response to concerns about a
>> >> CDNs in front of the ACME server, but in retrospect, they're solving
>> >> the wrong problem.  The risk posed by a CDN is that it swaps the keys
>> >> out, much like this situation.  So it's enough for the statement by
>> >> the domain owner (i.e., the validation object) to include an
>> >> indication of which account key he intends to authorize.
>> >>
>> >> This actually adds some symmetry to the challenges.  I had thought
>> >> that proofOfPossession seemed like the odd one out, since the account
>> >> key was being signed instead of doing the signing.  Your observation
>> >> that the domain holder needs to assert the key basically says that the
>> >> other challenges should follow the proofOfPossession model and have
>> >> the domian owner make a statement about the account key.  It's just
>> >> that in the other cases, the authenticity of the statement won't be
>> >> shown with a signature, but with its being provisioned in a particular
>> >> place.
>> >
>> > Exactly.
>> >
>> >> We will probably want to bind some more stuff into the validation
>> >> object besides the public key, though, in order to bound replay
>> >> opportunities.  At the very least, there needs to be a token that the
>> >> CA can use to associate the validation object with things like which
>> >> identifier is being authorized, and what type of challenge it goes
>> >> with (to prevent replay for different domains, or in different
>> >> channels).
>> >
>> > I may be overlooking something, but I'm skeptical of the value of
>> > including extra information.  If an attacker can replay a validation
>> > object for another domain or in the context of a different challenge,
>> > that means the attacker effectively controls that domain/validation
>> > channel, and can just contact the ACME server, start a new challenge,
>> > and complete it "normally" without any need for replays.
>> >
>> >> In light of the above, ISTM that the right tactical move is probably
>> >> to define a standard validation object that many challenges can use.
>> >> Then the proofOfPossession challenge can sign the validation object,
>> >> and the "put it here" challenges can provision a digest of the
>> >> validation object.
>> >
>> > That seems like a great way to simplify the protocol.  On the other
>> > hand, Jacob's /.well-known/certificate/acme-account-keys.json idea is
>> > also quite nice.
>> >
>> > Regards,
>> > Andrew
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> --
> konklone.com | @konklone