Cryptographically secure random UUIDs

[bcoe]

Ya ya yawm TAG!

I'm requesting a TAG review of uuid.

We propose adding the randomUUID() method to the crypto interface. This method provides an API for generating RFC 4122 identifiers. Initially, the only version of UUID supported will be the version 4 "Algorithm for Creating a UUID from Truly Random or Pseudo-Random Numbers".

• Explainer¹: /~https://github.com/WICG/uuid/blob/gh-pages/explainer.md
• Specification URL: https://wicg.github.io/uuid/
• Tests: https://chromium-review.googlesource.com/c/chromium/src/+/2804758
• Security and Privacy self-review²: https://docs.google.com/document/d/1M6E82C2Dgf9X7m4XTIRCiv5ktSIaOMR9-yhZtv9LQsE/edit?usp=sharing
• GitHub repo (if you prefer feedback filed there): /~https://github.com/WICG/uuid
• Primary contacts (and their relationship to the specification):
  • Ben Coe: Google.
  • Christoph Tavan: Google
  • Robert Kieffer: Community contributor.
• Organization(s)/project(s) driving the specification: Although several Googlers are working on this, we are doing so outside of our day jobs, so this work is largely being funded by our own individual spare time and interest.
• Key pieces of existing multi-stakeholder review or discussion of this specification: original tc39 issue tracker, WICG issue tracker.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5689159362543616

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: n/a.
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C.
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Although several Googlers are working on this, we are doing so outside of our day jobs, so this work is largely being funded by our own individual spare time and interest.

You should also know that...

This specification was originally worked on in TC39, but it was determined that the need for a CSRNG made WICG a more appropriate venue, given that WebCryptography is part of the web platform.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

---

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.

¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

[cynthia]

Early feedback before a group discussion.

If the specification were to add support for other UUID types, what would be the path forward? An optional argument to randomUUID()?

Aside from that question, this looks both useful and well-scoped.

[bcoe]

If the specification were to add support for other UUID types, what would be the path forward? An optional argument to randomUUID()?

As UUIDs are defined today, i.e., a 128-bit number, it's difficult to imagine a better algorithm than version 4 (as it maximizes entropy). However, I can imagine some futures where this might change:

• perhaps the definition of a UUID is extended to include more bits of entropy, at which point it would be nice to be able to request this crypto.randomUUID({bitSize: 256}).
• perhaps an algorithm gains popularity that is both random, and sequential, for some applications it might be nice to opt into this crypto.randomUUID({algorithm: 'v?');

For potential extensions to the method like this, I like the idea of an options object.

[cynthia]

it's difficult to imagine a better algorithm than version 4

Right, this was a question because several other languages support multiple versions and there might be demand for that after this ships.

For potential extensions to the method like this, I like the idea of an options object.

Yes, this looks like a sensible path forward. Thanks for the clarification!

[bcoe]

During the review process, I would be grateful if folks could chime in on the discussion regarding secure contexts, on the WICG repository.

[torgo]

Hi @bcoe 2 questions - one is what does the multi-implementer support look like? Chrome Status currently says "no information"... secondly, what's the proposed venue for this beyond WICG?

[cynthia]

Left our thoughts on secure vs insecure (based on partial consensus) here: WICG/uuid#23 (comment)

[bcoe]

Hey @torgo (I believe we me in London a few years ago, makes me nostalgic for travel), answers below:

what does the multi-implementer support look like?

• There is a thread open with the WebKit folks, which so far has no replies.
• We have productive ongoing conversation with Mozilla, re: their standards position.

what's the proposed venue for this beyond WICG

A few ideas have been floated:

• even though this feature is in the crypto namespace, since it does not have dependencies on Web Crypto beyond the CSPRNG, perhaps it could be worked on in another venue, such as WHATWG or WebAppSec.
• another idea floated was that perhaps this feature is small enough that it could be added independently from a WG to the editor's draft (@annevk felt that this might present IP concerns).

I don't have strong opinions, and am open to whatever process would create the least friction.

[torgo]

Thanks for the quick reply @bcoe – we discussed again in our plenary call just now. We think WebAppSec could be a good option - presuming the wg chair agrees. Good to hear there are discussions going on with other engines.

[cynthia]

We discussed this during our plenary this week, and the group is happy with the design. We left our feedback on the secure vs. insecure discussion (WICG/uuid#23 (comment)) with a group conclusion that this feature should be available in insecure contexts to discourage rolling your own crypto. Thanks for bringing this to our attention!

[annevk]

That conclusion seems rather inconsistent with Web Crypto itself being limited to secure contexts to avoid having the browser crypto internal code be accessible in insecure contexts. (Limited to randomness it would be more reasonable as that's already exposed.)

[cynthia]

That's a good point, maybe we should continue that discussion in the spec repo.

[Sainan]

Not that it really matters now that this feature is already well-established, but as a netizen, I am disappointed that this feature is limited to "secure contexts."

I do understand that cryptographic primitives like key generation should not be available in insecure contexts to avoid developers assuming something is secure when a MITM attack could compromise their app.

However, I don't think this justification applies to crypto.generateUUID() as it is pretty basic primitive function that, if it were cryptographically unsound, would realistically not have any adverse effects. Making this function unavailable for arbitrary reasons just gives the (insecure) web a smaller standard library — and the web is already bad enough without such sabotage.