On Wed, Aug 26, 2009 at 1:13 PM, Matthew
Toseland<[email protected]> wrote:
> 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.
That doesn't work unless the top level site is a CHK, which sucks :/
>>
>> 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 idea is that r...@crypto/ holds the revocation for s...@crypto/ .
Manifests would be disallowed as well; you only need the one default
file.
>>
>> 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.
Not completely pointless. If a seriously problematic bug made it into
one of the auto-updates, it might be nice to revoke just that build in
a way that would prevent nodes from installing that build, but didn't
represent a compromise of the key. Pushing a new update isn't a
complete substitute, because it's slower (especially if the bug takes
time to fix).
Similarly, if a large site (like, say, one of the spider indexes) is
accidentally published with an error, it might be nice to have clients
keep using the old version until the new one can be published (which
might take a day or three, given the size of such an index).
>>
>> 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?
Well, I hadn't been trying to design revocable SSKs that can be un-revoked :)
The idea was that the mere presence of the RSK key indicated a revoke.
It didn't matter what the data was, and once the key exists there are
no error conditions possible that prevent the revoke from being valid.
The idea was that Alice would publish a SSK site. Bob would generate
his own SSK keypair. Alice would give Bob a blob that is the revoke
for her site ( r...@alice_key/ ). It would contain something like
"revoker: Bob\ndetailed message:
s...@bob_key/alice-site-revoke/detailed_message.txt". Alice could give
several (different) such blobs to several trustees. Each would insert
to the same RSK, but with different contents. The contents, including
Bob's SSK for details, are set at blob creation time, so bob's SSK
needs to be known in advance. It doesn't matter who inserts the
revoke, what the message is, or whether the attacker inserted it with
their own message; the message is purely informational, and its
presence, absence, or validity has no impact on the validity of the
revoke. This has the advantage that in normal operation (the site is
not revoked) there's only one extra key I need to poll for (or, with
fine-grained revokes, two: one for the whole site, and another for the
specific file).
(I'll give some more thought to the multi-trustee un-revoking idea,
but I don't have any specific comments right now. My proposal assumed
that once the key was compromised, you would revert back to however
you originally established the trust chain.)
>>
>> 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...@.
In my proposal, there is no further payload. The RSK corresponds the
the SSK, and any payload is handled at by the SSK.
Looking at it now, what I've been calling RSKs in the proposal need a
name change, because really the proposal has three key types involved.
There are old-style, non-revocable SSKs. There are new, revocable
SSKs (called RSKs). There are revocation keys (call it RKD@, for
revocation key data, or something). If a user supplies
"r...@crypto/foo" it gets converted into a fetch for "s...@crypto/foo"
and (in parallel) a second fetch for "r...@crypto/" (and optionally for
"r...@crypto/foo" as well). And of course there's a corresponding
version for USKs ("r...@crypto/foo/n" -> "u...@crypto/foo/n" +
"r...@crypto/").
This has a (possibly small) speed advantage as well: if the RSK key
contains a payload (as in your version), then the first fetch must
complete before we can start looking for the revocation. In my
proposal, as soon as the user supplies the key, we simultaneously
start fetching the data (on the assumption that it won't be revoked,
however we don't display it until we know) and the revocation key.
>>
>> 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.
I'm inclined to agree.
>>
>> 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.
In the API, but not the UI. An easy to use UI for all three steps is
critical to RSKs actually being useful. Are these capabilities
available through FCP?
Evan Daniel
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
