Add support for noncing requests.

[mikewest]

Right now, we allow the nonce signature input parameter, but there's little benefit in using them. There's nothing forcing you to use nonces, nothing checking the nonces, and therefore little benefit to using them.

I'm imagining we'd add that in the future by tacking an option onto the integrity attribute (e.g. integrity="ed25519-[key goes here]?nonce=12345), and adjusting the Accept-Signature header's content accordingly to include that attribute as part of the request.

[punkeel]

QQ - should the page pick the nonce? Vs letting pages opt into using a nonce, and letting the user-agent generate a nonce.

[mikewest]

A reasonable question. I'd imagined the page defining the nonce, but it'd certainly be possible for the UA to define one on the page's behalf. That might simplify the story for developers, and I'm not sure there's any reason to expect developers to really want to define their own challenge, given that they're not at all involved in validating the response. 🤷

[ddworken]

I think the answer here depends on what security goal we're trying to achieve with nonces? Traditionally, nonces are "numbers used once", so having them be statically defined in the HTML (like in the integrity="ed25519-[key goes here]?nonce=12345 example) seems somewhat weird to me.

IMO, the main reason to use nonces would be if a website wanted to ensure that the backend still had access to the signing key. In which case having the user-agent generate the nonce seems like it might be the reasonable behavior?

I'll also say that if we aren't sure of the motivation for noncing, that may be a reason to defer adding support for nonces until there is a clear need.

[mikewest]

I think the answer here depends on what security goal we're trying to achieve with nonces? Traditionally, nonces are "numbers used once", so having them be statically defined in the HTML (like in the integrity="ed25519-[key goes here]?nonce=12345 example) seems somewhat weird to me.

Weirder than doing a very similar thing in CSP via <script nonce>? If we consider that dynamic-enough, it seems clear that we could consider other ways of defining a nonce in markup to be equally dynamic.

IMO, the main reason to use nonces would be if a website wanted to ensure that the backend still had access to the signing key. In which case having the user-agent generate the nonce seems like it might be the reasonable behavior?

Had access to the signing key certainly, but also remained willing to sign a given resource. The goal, AFAIR, is to defend against rollback attacks. I don't think that's something we need to worry about in an initial implementation (because I think expiration will be good enough), but I think we agreed that nonces/challenges might be a reasonable way of addressing it if we needed to.

[ddworken]

Got it, that all makes sense. IMO, I don't see too much utility in having the nonce be user-controlled, so I'd lean towards having the browser control the nonce.

Though given this security goal, I have what may be a somewhat radical idea--what if we had the browser always send a nonce? The backend could choose to include it in the signature base (in which case the browser would automatically validate that it matches the one in the request) or it could not include it (in which case the signature would be cacheable). This idea stems from the fact that I'm actually not entirely sure if we need pages to opt-in to noncing. It seems like it would also be perfectly reasonable for servers to opt-in to noncing if they want to protect their own resources against rollback attacks. WDYT?

[mikewest]

Got it, that all makes sense. IMO, I don't see too much utility in having the nonce be user-controlled, so I'd lean towards having the browser control the nonce.

I think either of these models can work, and I don't think choosing one or the other fundamentally changes the security protections nonces could provide.

That said, I also continue not to think any of this is a priority, and it can be easily layered in later. I'd suggest we keep this labeled as an "enhancement", and come back to it if/when someone has stronger motivation than I do at the moment. :)

Though given this security goal, I have what may be a somewhat radical idea--what if we had the browser always send a nonce? The backend could choose to include it in the signature base (in which case the browser would automatically validate that it matches the one in the request) or it could not include it (in which case the signature would be cacheable).

This reminds me of another great/terrible idea for a different thing we could do if we relied on browsers to send (and remember) a nonce along with requests: https://github.com/mikewest/strict-csp-for-everyone. :)