Doesnt the request have to be signed and stuff anyway by the account key? Am 25.11.2016 16:44 schrieb "Sam Kuper" <[email protected]>:
> 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
