Hi Sam, 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.
This seems reasonable, I would also be supportive of a change like this. > 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! 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 On Fri, Nov 25, 2016 at 10:08 AM, Sam Kuper <[email protected]> wrote: > 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
