On 08/07/2016 06:55 PM, Richard Barnes wrote: > Could you comment a little more specifically on what issues this has > caused you?
We turned on caching at our CDN, which led to some clients getting nonces that had already been used by other clients. A lot of clients didn't implement retries on badNonce, because in normally operation it's a relatively rare case. > As Ron notes, there's a need for some way to prime the nonce pump. Yup, agreed. rlb> Option 1: HEAD to some existing resource that admits a GET (e.g., directory) rlb> Option 2: GET/HEAD to a new-nonce resource rlb> Option 3: HEAD to the resource you would be POSTing to rlb> Option 4: POST an empty body to the resource you would be POSTing to; agwa> Option 5: make the protocol resilient to replays and remove nonces jsha> Option 6: POST an empty body to a new-nonce resource? jsha> Option 7: Don't require nonces for new-reg. Option 7 is not terribly appealing because it makes new-reg require different analysis for replay resistance. However, implementers already need different code to validate a new-reg request than to validate other requests, because the key in a new-reg request doesn't already exist. Similarly, option 5 allows getting rid of nonces, but at the cost of making the protocol harder to analyze. Each new request type created would have to be analyzed as to whether it was safe for replays. It's nicer, in my mind, to have one solution that covers the whole protocol. Right now I lean towards Option 6. Thoughts? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
