embed security metadata in URL #957

New Issue

zooko · 2010-02-15T06:11:28Z

zooko commented

2010-02-15 06:11:28 +00:00

In #956 it was described how "security metadata" such as highest-known-version-number to prevent rollback attack (#955), petrification-marker to revoke write authority (#954), or LAFS 301 Moved Permanently redirection marker (not yet ticketed) could be embedded into parent directories for stronger security and/or better performance.

In this ticket, let's consider that such security metadata could be embedded into the URL itself, so that people passing around URLs outside of Tahoe-LAFS directories would get the same benefits. The problem with this, of course, is that URLs are very space-sensitive (see #882 (Tahoe URIs and gateway URLs are too long and ugly)).

In #956 it was described how "security metadata" such as highest-known-version-number to prevent rollback attack (#955), petrification-marker to revoke write authority (#954), or LAFS 301 Moved Permanently redirection marker (not yet ticketed) could be embedded into parent directories for stronger security and/or better performance. In this ticket, let's consider that such security metadata could be embedded into the URL itself, so that people passing around URLs outside of Tahoe-LAFS directories would get the same benefits. The problem with this, of course, is that URLs are very space-sensitive (see #882 (Tahoe URIs and gateway URLs are too long and ugly)).

zooko added the

labels 2010-02-15 06:11:28 +00:00

zooko added this to the undecided milestone 2010-02-15 06:11:28 +00:00

zooko commented

2010-02-15 06:22:30 +00:00

I guess it doesn't make much sense to embed 301 Moved Permanently information into a URL. Instead, you just replace the URL with the new URL!

davidsarah commented

2010-02-16 00:36:01 +00:00

Replying to zooko:

... URLs are very space-sensitive (see #882 ...).

OTOH, we only need a few bits for this. The petrification marker is one bit, and the version number will usually be small, so we can use a variable-length encoding to encode low version numbers more concisely. In most cases I think it could be encoded with one extra character in a new URL format.

What is the typical distribution of version numbers?

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/6019): > ... URLs are very space-sensitive (see #882 ...). OTOH, we only need a few bits for this. The petrification marker is one bit, and the version number will usually be small, so we can use a variable-length encoding to encode low version numbers more concisely. In most cases I think it could be encoded with one extra character in a new URL format. What is the typical distribution of version numbers?

warner commented

2010-02-16 05:11:26 +00:00

um, if the assumption is that once you pass a URL to someone out-of-band that they'll always keep using that same URL, then there's less value in putting some of these indicators into those URLs. Neither "moved permanently" nor "petrification" seems very useful in that context. "max-known-version" (i.e. "min-acceptable-version") is marginally more plausible: I could give you a URL that couldn't be rolled back to anything from before the time I computed the URL. You get no protection from subsequent updates+rollbacks, though.

It sounds like there should be some optional extra fields in a URL. These fields are allowed to make the URL longer than we'd necessarily like to pass around, if the only place they'll be seen is in a dirnode childcap.

davidsarah: well, mutable file version numbers start at 0 and are incremented for each update, and live in an 8-byte field. We could compute the distribution for e.g. the prodnet grid, by building a "share report" (since the version number is outside the encrypted payload). But it depends entirely upon how long somebody has been using a given directory and how frequently they update it.

um, if the assumption is that once you pass a URL to someone out-of-band that they'll always keep using that same URL, then there's less value in putting some of these indicators into those URLs. Neither "moved permanently" nor "petrification" seems very useful in that context. "max-known-version" (i.e. "min-acceptable-version") is marginally more plausible: I could give you a URL that couldn't be rolled back to anything from before the time I computed the URL. You get no protection from subsequent updates+rollbacks, though. It sounds like there should be some optional extra fields in a URL. These fields are allowed to make the URL longer than we'd necessarily like to pass around, if the only place they'll be seen is in a dirnode childcap. davidsarah: well, mutable file version numbers start at 0 and are incremented for each update, and live in an 8-byte field. We could compute the distribution for e.g. the prodnet grid, by building a "share report" (since the version number is outside the encrypted payload). But it depends entirely upon how long somebody has been using a given directory and how frequently they update it.

zooko commented

2010-02-16 05:47:07 +00:00

I think you are right that there is no point in including "moved permanently" in a URL, since you instead just give them the new URL! (Well, there could be a point, which is to inform them that this new URL ought to replace that old one in their database.)

But there's surely a point to petrified -- because if you had a mutable file, and then you petrified it, and then you give the URL to someone, you don't want some sort of rollback attack letting them see an unpetrified file!

I think you are right that there is no point in including "moved permanently" in a URL, since you instead just give them the new URL! (Well, there could be a point, which is to inform them that this new URL ought to *replace* that old one in their database.) But there's surely a point to petrified -- because if you had a mutable file, and then you petrified it, and then you give the URL to someone, you don't want some sort of rollback attack letting them see an unpetrified file!

davidsarah commented

2010-02-16 20:21:33 +00:00

In order for a petrified URL not to be subject to a rollback attack, it would need to include a hash of the final contents (I was mistaken about this in comment:2). The final version number is not sufficient, if the write cap might have been compromised. Including a hash would make the URL huge. (I/we had some ideas about how to obtain relatively short caps to a specific version of a mutable object, but they're for the new cap formats.)

We're starting to think that petrification should be implemented in terms of permanent redirects ("moved permanently"). I.e. a petrified object is just a mutable object that has been permanently redirected to an immutable URI. To record that in a parent directory (#956), you would just update the link in the parent to point to the new URI.

The advantage of this is that you can upload the final contents (either a single file or a tree) as normal, check that they are correct, and only then make the redirect. Also you can permanently redirect to a new mutable object using the same mechanism, which is probably what you would want to do if you've accidentally given away a write cap.

In order for a petrified URL not to be subject to a rollback attack, it would need to include a hash of the final contents (I was mistaken about this in comment:2). The final version number is not sufficient, if the write cap might have been compromised. Including a hash would make the URL huge. (I/we had some ideas about how to obtain relatively short caps to a specific version of a mutable object, but they're for the new cap formats.) We're starting to think that petrification should be implemented in terms of permanent redirects ("moved permanently"). I.e. a petrified object is just a mutable object that has been permanently redirected to an immutable URI. To record that in a parent directory (#956), you would just update the link in the parent to point to the new URI. The advantage of this is that you can upload the final contents (either a single file or a tree) as normal, check that they are correct, and only then make the redirect. Also you can permanently redirect to a new mutable object using the same mechanism, which is probably what you would want to do if you've accidentally given away a write cap.

zooko modified the milestone from undecided to 2.0.0

2010-02-23 03:11:41 +00:00

zooko added

enhancement

and removed

defect

labels 2011-01-16 03:58:28 +00:00

meejah commented

2021-03-30 18:40:46 +00:00

Ticket retargeted after milestone closed (editing milestones)

meejah removed this from the 2.0.0 milestone 2021-03-30 18:40:46 +00:00

Sign in to join this conversation.