On Monday 27 July 2009 18:26:27 Evan Daniel wrote: > On Mon, Jul 27, 2009 at 9:18 AM, Matthew > Toseland<[email protected]> wrote: > > - RSKs: Important sites, particularly those distributing executables, need > > a revocation mechanism. This can be emulated with HTML UI elements, but is > > clumsy and problematic due to the various different error messages. > > Adding HTML UI elements on SSKs as the exist now has a major problem: > if Mallory obtains Alice's privkey, his first order of business > becomes inserting a new edition of the freesite that points to a > different revoke key than the one Alice gave Bob, thus preventing Bob > from revoking the site in a meaningful manner.
Right. Hence post the frame as a CHK site. But it is still not very good,
because some error messages can be quite confusing.
>
> I suggest something like the following, based on a chat I had with
> saces. The idea is to retrofit revocation capability onto existing
> SSKs without changing how SSKs work or breaking existing client
> software. There are probably lots of problems with the details :)
>
> Create a new keytype, r...@. This is treated exactly like an SSK
> internally (ie a translation layer similar to USKs), but has several
> differences. First, the namespace is different (mangled internally
> somehow) so that "r...@crypto/foo" and "s...@crypto/foo" are different
> keys. Second, the null filename is allowed ("r...@crypto/" is a valid
> key). Third, redirects are not allowed.
Why allow null key? It gets very confusing if you do that, and parsing can be
ambiguous - is this a manifest lookup in the null key or is it a non-null key?
Why no redirects? You can't fit much in a single SSK block! Oh, the RSK is just
the revocation, not the data with revocation protection?
>
> The usage is as follows: the RSK@ keyspace represents the revocation
> files for the SSKs with the same pubkey / crypto key. The null
> filename ("r...@crypto/") represents a revoke for the whole keyspace
> (key blown, etc). Non-null filenames ("r...@crypto/foo") represent
> finer-grained revokes for things like broken inserts (if you screw up
> an edition of a freesite and haven't yet inserted the fixed version,
> for example). I'm less certain I like the fine-grained revokes, but
> I'm mentioning them anyway for completeness; the remainder of the
> proposal would work fine with or without support for them.
IMHO fine-grained revokes are completely pointless because the question at
issue is whether there is a reasonable possibility that a bad guy might have
the private key for the whole keyspace.
>
> If the RSK key is found, then its existence indicates that the site
> has been revoked. It would contain, at a minimum, a message saying
> who revoked it. If I'm creating a freesite, and want to distribute
> revoke privs, I would generate a set of RSK binary blobs (which say
> things like "revoked by Alice" "revoked by Bob" etc), and distribute
> those to the relevant people. I could even generate several blobs for
> Alice, with different pre-defined revoke reasons.
Interesting. No customisable revoke message..
>
> (Optional extension) The RSK key could also include a set of places to
> look for further information. For example, a set of SSKs owned by the
> people with revoke privs, which could be used to implement voting
> rules or similar. Then, everyone would get a copy of the same blob
> that basically says "revoked by someone, see these keys for details".
> It could then specify eg four SSKs to check, with a rule that the
> revoke is valid if any two of the four are found. This could also
> implement revoker-definable reasons: I give Alice a revoke blob that
> says "revoked by Alice, see this SSK for the reason".
Ok, so in the naive implementation each trustee is given a blob that identifies
them and explains the specific pre-set failure mode. In which case any trustee
can insert his error blob, and there would be no way for the user to know the
trustee has gone bad. But the next step is for all of the blobs to contain the
list of extra data locations for each trustee. So we can query them and
determine that the blob was bogus, because the others said so.
HOWEVER, this opens up a more fundamental weakness: If the attacker obtains the
private key he can insert whatever he wants, including a bogus list of extra
data locations. He can ensure that no real revocation is inserted simply by
inserting a bogus revocation with extra data locations which all say it is
bogus. And this is not solvable with a single-fetch model AFAICS: We need to
publish the extra data locations *in advance*.
Clearly we don't want to encode it into the URI, as it would be ridiculously
long. And we don't want it to depend on a single privkey either. So we need an
RSK manifest. This should be in a CHK, or a SSK with a throwaway key. An SSK is
smaller and has better survivability; a CHK doesn't allow tampering even with
the throwaway key. It would contain:
- The target URI. Probably a USK.
- The blob URI. This is checked before moving on to the target URI.
- SSKs for each of the trustees.
- How many trustees are required to endorse a new RSK (0 = not allowed).
- How many trustees are required to endorse a new RSK in the case where a valid
blob has been inserted by one of the trustees (0 = not allowed).
- How many trustees are required to endorse a new RSK in the case where an
invalid blob has been found (0 = not allowed).
When fetching an RSK, we fetch the manifest. If it is not found, we fail. If it
is not formatted as a valid RSK manifest, we fail. We check the blob URI. If we
don't find the blob, we fetch the target URI: everything is fine, but we fetch
the trustees' SSKs in the background anyway to ensure good propagation. If we
do find a blob, and it is not a valid blob specifying one of the trustees and a
recognised failure mode, we fail. We fetch the trustees' extra data. If the
original RSK allows them to create a new RSK, and there are enough votes given
the conditions, we do a permanent redirect to the new RSK. If not, we display
all their messages.
I am uncertain whether the trustees' blobs should contain a nonce signed by
their SSK's privkey to identify themselves; this would complicate creating
them, so maybe not worth it.
Thoughts?
>
> Default settings for how to handle revokes are tricky. I propose that
> the key-revoke ("r...@crypto/") always be checked, and an error
> returned if found by default. There would then be a force-download
> option to allow clients to download the data anyway. File-specific
> revokes ("r...@crypto/filename") are less important, and offer more
> censorship possibilities, so they should not be checked by default.
> If a client is prepared to intelligently inform the user about them,
> it would turn on the option to check them.
>
> The logic behind prohibiting redirects is that this is not a
> general-purpose key, and we want to make DOS or spam attacks as hard
> as possible. Furthermore, any revoke message ought to fit in 1k.
Right ... but what about the payload? I had thought RSKs would check for the
revocation key, and if not found, then proceed to the target site, which is
most likely a redirect to a top block CHK? And clearly we don't want this to be
just in metadata, unless the CHK is metadata - we need it to be encoded into
the URI, by calling it RSK@ instead of s...@.
>
> This would need some changes internal to the node, but no network
> level changes or datastore changes. Because RSKs are just a different
> way of turning a pubkey + filename into a block ID, they are treated
> exactly the same as SSKs at a network and datastore level; all the
> changes would be confined to higher levels, much like USKs. Beyond
> simple code complexity issues, it is important that rare RSKs be able
> to hide amongst normal SSKs for security reasons.
Right.
>
> There is an argument in favor of some lower-level changes, but I think
> it is outweighed by the problems such changes cause. Basically, if my
> node is in possession of a revoke certificate for a key, it should
> never drop the revoke cert from its store while keeping the key it
> refers to. Otherwise, it's possible for the revocation of a site to
> be lost while the site itself remains accessible. Obviously, doing
> this would require some sort of low-level special treatment for
> revokes. However, I suspect that this is rare enough not to be a real
> issue.
I don't think a lower level solution would be a good idea. Generally storage
and propagation for SSKs is fairly good anyway.
>
> The major other thing this would require is support for binary blobs.
> At present, there are no user-level tools to handle them. As I see
> it, the minimum requirements are:
> - The ability to create a binary blob for a key and save it, without
> inserting that key. There would need to be a simple form wizard that
> generated revocation blobs in a correctly-formatted manner.
This we have, but not the UI.
> - The ability to verify a binary blob and read the data it contains.
> This would require also knowing the key it represents (AIUI, the blob
> normally contains the routing key but not the decryption key, just
> like the datastore). If Alice intends to revoke Bob's site, she
> probably wants to first check that the blob she is about to insert
> will do that (inserting the revoke for the wrong site would be bad).
> When she receives the revoke blob from Bob, she probably also wants to
> check that the revoke message says what Bob said it did. This
> verification step needs to not actually insert the blob.
This we sort-of have; you can pass a BlockSet on a request.
> - And, obviously, the ability to actually insert a blob that the user has.
This we have.
>
> Evan Daniel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
