As the veteran of many arguments about pseudorandomness and uniqueness, I think it's reasonable to consider a sufficiently long random string to be unique.
"high probability" actually makes it worse, because 99.99 is actually a very high probability but not really a security boundary. If you want to provide more guidance, I would suggest instead giving a minimum length for the random string. -Ekr On Tue, Mar 28, 2017 at 7:16 AM, Alan Doherty <[email protected]> wrote: > At 11:46 28/03/2017 Tuesday, Martin Thomson wrote: > >I agree with Jacob here. MUST seems appropriate, but requiring > >uniqueness absolutely imposes a constraint on server design that is so > >onerous that I would see it as impractical. (Also, the document > >doesn't really identify a scope for this uniqueness, which would > >probably be necessary if you had to avoid random generation.) > > > i think given a large enough set of transactions unique is impossible (and > guaranteeing a previous use in identical circumstances impossible, unlikely > but not guaranteeing) > thus as its impossible mathematically (unless using sequential numbers of > infinite length) > > its better to keep 'high probability' as the possibility of random > generating a sequence twice is always there, if its truly random > improbable can be done, impossible is infinitely more work (as would > require keeping all previous and negative matching an ever growing list > before use) > > > > >On 27 March 2017 at 16:46, Jacob Hoffman-Andrews <[email protected]> wrote: > >> Forwarding on behalf of Erica Portnoy. > >> > >> I agree, the uniqueness should be a MUST, but I think "high probability" > >> should stay so random generation of nonces is acceptable. PR: > >> https://github.com/ietf-wg-acme/acme/pull/289 > >> > >> > >> -------- Forwarded Message -------- > >> Subject: Generating nonces probabilistically in 6.4.1. > Replay-Nonce > >> Resent-Date: Fri, 24 Mar 2017 18:19:35 -0700 (PDT) > >> Resent-From: [email protected] > >> Resent-To: [email protected], [email protected], [email protected] > >> Date: Fri, 24 Mar 2017 18:03:53 -0700 > >> From: erica <[email protected]> > >> To: [email protected] > >> > >> > >> > >> In section 6.4.1. Replay-Nonce, it states: "The server should generate > >> the value provided in Replay-Nonce in such a way that they are unique to > >> each message, with high probability." > >> > >> Should this not be: "The server MUST generate the value provided in > >> Replay-Nonce in such a way that they are unique to each message." > >> > >> This is actually two separate items: > >> - First, that the server must, not should, generate a unique > >> Replay-Nonce. I can't imagine that we're ok with the spec allowing a > >> server to come under replay attacks, so this should probably be MUST. > >> - Second, do Replay-Nonces need to be certainly unique to each message? > >> Or are we merely attempting to mostly rule out replay attacks? If we > >> want to disable them completely, not just with extremely high > >> probability, then we should remove "with high probability". > >> > >> Best, > >> Erica Portnoy > >> > >> > >> _______________________________________________ > >> Acme mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/acme > > > >_______________________________________________ > >Acme mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
