On Sat, Aug 6, 2016 at 2:55 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> At IETF 96 it was proposed to drop this issue: > https://www.ietf.org/proceedings/96/minutes/minutes-96-acme. > > The rationale from the notes is that nonces are not a scarce resource. > However, cachability and idempotence of GETs were not addressed. I think > it's worth not requiring nonces on GETs purely for those reasons. In > practical terms, this difference has caused real bugs for Let's Encrypt. > Could you comment a little more specifically on what issues this has caused you? > Would someone like to present a specific defense of providing a unique > nonce with every GET? > As Ron notes, there's a need for some way to prime the nonce pump. Because POSTs require nonces, that means that we need either use a non-POST method or modify POST behavior. Let me propose a few options for people to opine on... Option 1: HEAD to some existing resource that admits a GET (e.g., directory) Pro: Aligns with HTTP's requirement for GET == HEAD if you also send Replay-Nonce for the GET Con: ... but sending Replay-Nonce for the GET makes the affected resource non-cacheable Option 2: GET/HEAD to a new-nonce resource Pro: Clean separation of the nonce-priming function Con: One more resource to specify / provision / remember Option 3: HEAD to the resource you would be POSTing to Pro: Simple client logic; no need to use a separate resource Con: Contrary to a SHOULD in RFC 7231, especially when the resource doesn't respond to GET Option 4: POST an empty body to the resource you would be POSTing to; get nonce in error response Pro: Client can use the same resource; priming POST can't be mistaken for a real POST Con: Client and server need a special case in their POST logic I think my preference order would be 3 ~= 4 > 2 > 1, but I don't have strong feelings here as long as we end up with something predictable for the client to do. --Richard > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
