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

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

Reply via email to