Subject: [OAUTH-WG] HTTP signing spec and nonce

From: "Brock Allen" <[email-masked]>
Date: Fri, 26 Feb 2016 09:49:54 -0500

Question about the HTTP signing spec - why is there no nonce (and just a
timestamp)?

TIA

-Brock

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Feb 2016 21:47:40 -0500

I’d be glad to add in a nonce if there’s a compelling reason for it, such as closing a security attack vector.

What’s the proposed purpose of the nonce? Is it just to add randomness to the signing base? Or is it to prevent replay at the RS? If the former, the timestamp should add enough of that and it can be verified to be within a reasonable window by the RS by comparing it with the time the request was made. If the latter, the RS is going to have to track previously used nonces for some amount of time. 

There was a small discussion of just signing an outgoing “Date:” header instead of the separate timestamp, but the timestamp seemed to be more robust. I forget the full reasoning though.

 — Justin

> On Feb 26, 2016, at 9:49 AM, Brock Allen <[email-masked]> wrote:
> 
> Question about the HTTP signing spec – why is there no nonce (and just a timestamp)?
>  
> TIA
>  
> -Brock
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dominick Baier <[email-masked]>
Date: Sat, 27 Feb 2016 08:06:33 +0100

The nonce would allow to build a replay cache, the timestamp to trim that cache and reject messages that are too old.

Similar protocols have a nonce for the above reasons (ws-sec msg security, hawk)...

— 
cheers
Dominick Baier

On 27 February 2016 at 03:48:00, Justin Richer ([email-masked]) wrote:

 — Justin

 
TIA
 
-Brock

---

From: Justin Richer <[email-masked]>
Date: Sun, 28 Feb 2016 13:34:01 -0800

I understand how they work, I’ve built exactly that cache before. But I askWouldn’t a unique timestamp have the same effect? Currently it’s integer seconds but slicing that down further (floating point seconds?) if people desired would allow for multiple signed messages in the same second from the same client using the otherwise same parameters. 

“Other protocols do it” is not a compelling reason on its own, especially when the example of “other protocols” includes WS-* ;)

Seriously though, an optional nonce is easy to add to the draft if there’s enough WG support, I’m just hesitant to add more complexity than needed to this.

 — Justin

> On Feb 26, 2016, at 11:06 PM, Dominick Baier <[email-masked]> wrote:
> 
> On 27 February 2016 at 03:48:00, Justin Richer ([email-masked] <mailto:[email-masked]>) wrote:
> 
>>> On Feb 26, 2016, at 9:49 AM, Brock Allen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]>

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 29 Feb 2016 08:42:28 +0100

To me it seems reasonable that a client may send multiple signed messages
in one second.

So I´m +1 for a nonce. A more fine grained timestamp is nice but I think we
might end upp at the same place, someone saying that they think it is
reasonable to send multiple signed messages the same millisecond.

//Samuel

On Sun, Feb 28, 2016 at 10:34 PM, Justin Richer <[email-masked]> wrote:

> I understand how they work, I’ve built exactly that cache before. But I
> askWouldn’t a unique timestamp have the same effect? Currently it’s integer
> seconds but slicing that down further (floating point seconds?) if people
> desired would allow for multiple signed messages in the same second from
> the same client using the otherwise same parameters.
>
> “Other protocols do it” is not a compelling reason on its own, especially
> when the example of “other protocols” includes WS-* ;)
>
> Seriously though, an optional nonce is easy to add to the draft if there’s
> enough WG support, I’m just hesitant to add more complexity than needed to
> this.
>
>  — Justin
>
> The nonce would allow to build a replay cache, the timestamp to trim that
> cache and reject messages that are too old.
>
> What’s the proposed purpose of the nonce? Is it just to add randomness to
> the signing base? Or is it to prevent replay at the RS? If the former, the
> timestamp should add enough of that and it can be verified to be within a
> reasonable window by the RS by comparing it with the time the request was
> made. If the latter, the RS is going to have to track previously used
> nonces for some amount of time.
>
> There was a small discussion of just signing an outgoing “Date:” header
> instead of the separate timestamp, but the timestamp seemed to be more
> robust. I forget the full reasoning though.
>
>  — Justin
>