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

[Eric Rescorla]

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  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  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:alias-boun...@ietf.org
> >> Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
> >> Date:   Fri, 24 Mar 2017 18:03:53 -0700
> >> From:   erica 
> >> To: draft-ietf-acme-a...@ietf.org
> >>
> >>
> >>
> >> 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
> >> Acme@ietf.org
> >> https://www.ietf.org/mailman/listinfo/acme
> >
> >___
> >Acme mailing list
> >Acme@ietf.org
> >https://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Alan Doherty]

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  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:alias-boun...@ietf.org
>> Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
>> Date:   Fri, 24 Mar 2017 18:03:53 -0700
>> From:   erica 
>> To: draft-ietf-acme-a...@ietf.org
>>
>>
>>
>> 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
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>
>___
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Martin Thomson]

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  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:alias-boun...@ietf.org
> Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
> Date:   Fri, 24 Mar 2017 18:03:53 -0700
> From:   erica 
> To: draft-ietf-acme-a...@ietf.org
>
>
>
> 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
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Erica Portnoy]

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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jacob Hoffman-Andrews]

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:alias-boun...@ietf.org
Resent-To:  r...@ipv.sx, j...@eff.org, jdkas...@umich.edu
Date:   Fri, 24 Mar 2017 18:03:53 -0700
From:   erica 
To: draft-ietf-acme-a...@ietf.org



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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme