Subject: [Acme] Generating nonces probabilistically in 6.4.1. Replay-Nonce

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 27 Mar 2017 14:46:18 -0700

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-masked]
Resent-To: 	[email-masked], [email-masked], [email-masked]
Date: 	Fri, 24 Mar 2017 18:03:53 -0700
From: 	erica <[email-masked]>
To: 	[email-masked]

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 05:46:40 -0500

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.)

On 27 March 2017 at 16:46, Jacob Hoffman-Andrews <[email-masked]> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Alan Doherty <[email-masked]>
Date: Tue, 28 Mar 2017 13:16:28 +0100

>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)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 30 Mar 2017 12:51:16 -0500

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-masked]> wrote:

> 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)
> 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)
>
>
>