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

[Eric Mill <[e-mail]>]

On Thu, Aug 13, 2015 at 1:42 AM, Richard Barnes <[e-mail]> wrote:

> 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.
>

Yep, I get that. I might be misreading it, but it looked like the
suggestion of a /.well-known URI for account keys would impact all ACME
users, not just those using Simple HTTP validation.

-- Eric


>
>
> >
> > -- 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
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>