Subject: [Acme] Nonces and replay attacks

From: Sam Kuper <[email-masked]>
Date: Fri, 25 Nov 2016 15:08:19 +0000

Dear all,

I am new to this mailing list, and am likewise new to reading the draft
ACME protocol with a critical eye. I hope to avoid committing any
blunders, but ask your forbearance for my newness, should I fail.

draft-ietf-acme-acme-04, section 5.5 contains two pieces of text that I
think could be improved. These improvements would be substantive to the
protocol, not merely editorial, which is why I am raising them on the
mailing list.

The first piece of text is this:

> When a server rejects a request because its nonce value was
> unacceptable (or not present), it SHOULD provide HTTP status code 400
> (Bad Request), and indicate the ACME error code
> "urn:ietf:params:acme:error:badNonce".

I can see no good reason for this to be "SHOULD" rather than "MUST".
Please can it be changed to "MUST"? Otherwise, a client might have no
way of knowing why the request failed, and therefore no reasonable way
to proceed.

The second piece of text is this:

> An error response with the "badNonce" error code MUST include a
> Replay-Nonce header with a fresh nonce. On receiving such a response,
> a client SHOULD retry the request using the new nonce.

That looks dangerous to me. If the server implements the requirement
above, then when Mallory's attempt to replay Alice's request has just
failed, the server will reply with a fresh nonce, thereby
potentially giving Mallory the means to usurp Alice's session. Ouch!

That being so, a suitable replacement for the second piece of text
quoted above would be:

> An error response with the "badNonce" error code MUST NOT include a
> Replay-Nonce header with a fresh nonce. On receiving such a response,
> a client SHOULD log it and attempt to notify its human operator that
> the server has reported evidence of a replay attack.

Best wishes,

Sam

---

From: Philipp Junghannß <[email-masked]>
Date: Fri, 25 Nov 2016 16:46:49 +0100

Doesnt the request have to be signed and stuff anyway by the account key?

Am 25.11.2016 16:44 schrieb "Sam Kuper" <[email-masked]>:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 25 Nov 2016 11:07:33 -0500

Hi Sam,

> way of knowing why the request failed, and therefore no reasonable way

This seems reasonable, I would also be supportive of a change like this.

> potentially giving Mallory the means to usurp Alice's session. Ouch!

You start by talking about an adversary that is replaying existing
messages,
which causes the badNonce error when the request is replayed the second
time. But when you say "potentially giving Mallory the means to usurp
Alice's session", that would require the adversary construct a new signed
message using the nonce without the participation of Alice - this shouldn't
be
possible in the MITM threat model that the nonce usage is meant to address.

Am I misunderstanding something?

- Daniel

---

From: Sam Kuper <[email-masked]>
Date: Fri, 25 Nov 2016 16:26:50 +0000

> Doesnt the request have to be signed and stuff anyway by the account key?

Yes, but such a signature would at most prove authenticity and
integrity w.r.t. the request: it would not say anything about whether
or not the request is a replay. The reason for having anti-replay
nonces in addition to signatures is that, used correctly, they protect
against a class of attacks that signatures alone do not prevent
against.

START ILLUSTRATION

Suppose, for example, that Alice has become incapacitated (or, if
Alice is a business, suppose Alice has gone out of business) and as a
result, Alice's web server, which was protected by certificates
obtained via ACME, is no longer under Alice's control. Suppose further
that Mallory has obtained control of Alice's web server, and wants
users to think that Alice is still in control of it.

Mallory might be able to succeed in that attempt (for example, by
requesting up-to-date certificates in Alice's name), if Mallory were
able to successfully perform replay attacks, even if Mallory did not
have Alice's private key.

END ILLUSTRATION

Maybe not the best illustration, and I haven't grokked ACME well
enough yet to be sure whether anything else in ACME would mitigate
against such an attack, but hopefully this at least helps to clarify
my point.

---

From: Sam Kuper <[email-masked]>
Date: Fri, 25 Nov 2016 16:36:08 +0000

Hi Daniel,

> This seems reasonable, I would also be supportive of a change like this.

Excellent. Thank you.

> possible in the MITM threat model that the nonce usage is meant to address.

Ah, indeed, if the request must contain the new nonce and be signed
with Alice's private key, then you are correct, and my previous reply
(to Philipp) was overly hasty.

Thanks for your explanation, and apologies to Philipp for my misunderstanding.

Sam

---

From: Philipp Junghannß <[email-masked]>
Date: Fri, 25 Nov 2016 18:15:44 +0100

well wouldnt make much sense to use a nonce in the first place, if it isnt
in the signature.

but a nonce is a number which should only be used once, and since it's
generated at random, there is no reason why the server shoudnt throw a
proper nonce e.g. if the randomizer of Alice's system is crap or whatever.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 25 Nov 2016 17:03:22 -0500

> > This seems reasonable, I would also be supportive of a change like this.

Works for me.  One of you guys want to send a PR?

--Richard

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 25 Nov 2016 17:54:09 -0500

> Works for me.  One of you guys want to send a PR?

Sam has sent one in: https://github.com/ietf-wg-acme/acme/pull/214

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Nov 2016 23:31:43 +0000

> but a nonce is a number which should only be used once, and since it's generated at random

The first part is right, the second part is not strictly correct.