RE: UUID version 6 proposal, initial feedback

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Brad,

I'm no expert on UUID's but some thoughts (as an individual contributor):

What you describe does sound to me like it could be a new form of UUID (if limited to a 128 bit format), and it could potentially also be useful.  E.g. a 128 bit UUID that has good database locality properties and minimizes the leakage of private information sounds useful if it can be reasonably specified and implemented.

I also note that RFC 4122 is 15 years old, and as Martin previously indicated there are security and privacy considerations that have evolved over time, hence updating RFC 4122 to make readers aware of those considerations also seems like it could potentially be useful.

Writing this up as a draft sounds like a good next step to see if there is enough wider interest.

Regards,
Rob


-----Original Message-----
From: ietf <[e-mail]> On Behalf Of Brad Peabody
Sent: 04 February 2020 10:05
To: Theodore Y. Ts'o <[e-mail]>
Cc: IETF discussion list <[e-mail]>
Subject: Re: UUID version 6 proposal, initial feedback


> For very specialized use cases (e.g., where 16 binary bytes is too 
> long), I'm not sure it makes sense to create a fully general 
> specification which is so abstract that it becomes hard to use, since 
> you have to customize it for a particular application.
>
> Past a certain point, you might as well say that you want to 
> standardize "b-trees" --- and that's something which belongs in an 
> algorithms book, and not an I-D or an RFC.
>
In practical terms, the issue I'm concerned about is that there are various points where software from different projects needs to communicate UUIDs to each other and so it turns from a general thing into something very specific. In this link I mentioned earlier
https://github.com/uuidjs/uuid/issues/303#issuecomment-575992079 it's all about how UUIDs work with Postgres as primary keys.

The text encoding is particularly relevant, since hexes with dashes is not a particularly practical format (too long) for a many use cases.  So if you have a column in a database of type 'UUID' (or some other similar ID type) and then issue an update statement - there needs to be known text format and it would be great if it were more compact.   And if it were standardized then eventually various databases would implement it. The sorting is also a thing - see below.

But I do get what you mean on shorter IDs with less uniqueness guarantee
- a spec isn't need to just generate a random opaque string that you're just going to have to check a database for to ensure you don't have a duplicate.

> Again, I'd urge you to consider that you should build on *top* of the 
> standard UUID spec, since there are already implementations that will 
> do the right thing as far as time-based and random-based UUID's (the 
> latter will provide all the unguessability you need) and then just 
> create a library which *transforms* the UUID into a convenient 
> encoding form that makes it be convenient for key-indexing, or a more 
> compact text encoding, etc.
>
> There are already very good implementations for UUID generation, and 
> if you create something which re-invents the wheel at a spec level, it 
> will cause people to reinvent the wheel (possibly badly) at the 
> implementation level.

I think a part of the issue here is that since there is an existing UUID spec people then try to use it for things like database keys, and then run into these various rough edges:

- hex text format too long

- sorting is extra work for no benefit, having the raw bytes sort naturally in time sequence (for UUIDs with a timestamp) would seem to be a better way

- there is no official form of UUID that has a timestamp and then random data - the spec says to use the MAC address of the machine (version 1) which can be a security issue; and version 4 is not time-ordered.

So that's more info on the motivation and, at least from my perspective, the practical concerns that are driving this.

It would certainly be less of a change to just propose an update to the UUID spec that puts the date in a sequence that sorts as raw bytes and says feel free to use random data from a properly seeded CSPRNG instead of a MAC address if you're willing to have X collision probability in exchange for not having your MAC address there.  And also says btw hex encoding is big, so feel free also to use base32 or base64 according to what you want for your app. It would be great if these things had good names too so that when someone goes to implement this in a new database column type they can be referred to with sane names that match the spec.  Those points might be all it would take. And that was more or less my original intention with coming up with the original "UUID version 6" concept.

At the end of the day I guess the main driving use case is as a database primary key (and then also being able to easily use that PK in the same human readable form in things like URLs or written in documents), but the above sillyness ("rough edges") make this difficult with the current specification.