"No-Keyserver" (and other) flags on keys

[David Shaw]

On Jun 28, 2010, at 12:47 AM, Dan Mahoney, System Admin wrote:

> On Sun, 27 Jun 2010, David Shaw wrote:
> 
>>>>> However, you raise another question: How does a keyserver know who is uploading the key?
>>>> 
>>>> At the moment, it doesn't.  That would need to be addressed if you want keyservers to be able to reject a no-ks-modify key.  One way to do it is to only accept key updates that are signed by the key itself. But, of course, to do that, the keyserver needs to be able to verify a signature...
>>> 
>>> That's one way.  Another is to do it the keyserver.pgp.com way, and email the primary uid a cookie.  No crypto required.  RFC2440 doesn't at all require that the authenticity be verified cryptographically. Correct?
>> 
>> Correct, but then, RFC-2440 or 4880 doesn't say much about keyservers at all.  It's mainly a message format document.  Semantics of keyservers are not specified beyond one or two minor things like the no-modify flag and the "preferred keyserver" field.
>> 
>> The difficulty with mailing the primary user ID a cookie is that it pretty much means your server can't synchronize with any other server.
> 
> Keyserver A updating keyserver B for key "foo" would in essence be someone other than the owner, even if they're in the same "pool", as keyservers can have multiple names.

The difficulty in transferring the owner's intent to update from server A to server B is one of the reasons why a server that does honor no-modify can't easily sync with other servers.  It's not impossible, but would require a whole new method of synchronization to accommodate the extra signatures involved.  Syncing from a server that honors no-modify to one that doesn't honor it is even worse.

> I presently consider synchronization broken.  If there were only one network of keyservers out there, and I didn't have to search multiple places when trying to sign or request a key, I might think otherwise, but this is not the case.  See my alternate request about being able to use multiple urls in auto-key-locate, which I don't believe currently works.

It does.

  auto-key-locate  hkp://pgp.mit.edu  hkp://subkeys.pgp.net  hkp://some.other.server.etc  ldap://even.a.ldap.server.works

List as many as you like, they'll be tried in order.

>>> However, I think you're still missing my question: is it necessary for the keyserver to be crypto-aware if I just want a keyserver to reject those keys outright?  Is there crypto involved in reading that flag, or is it just a simple parse?  From reading RFC2440 it seems the latter, but I certainly respect you've been doing this longer than I :)
>> 
>> There is crypto involved in showing that the flag is real - that the keyholder set the flag, and not someone just setting the flag for malicious reasons.
> 
>> For example, take the case of a key with the no-modify flag set (i.e. the keyholder doesn't want the key on a keyserver).  The attacker takes this key, and removes the flag.  He then sends the key to a keyserver without crypto.  The keyserver sees the key has no flag, so accepts it. This allows an attacker to violate the keyholder's requirements.  If the keyserver had crypto, it would know that the key had been tampered with and the flag removed.
> 
> At present, no keyservers respect this flag, with or without crypto.  So that's not much of a leap, anyway.  This "attack vector" exists now. 

No, it doesn't.  At the moment we have a set of servers that clearly and explicitly do not have support for this.  There is nothing to attack here - you can't fool a server into accepting something it shouldn't, when the server by design accepts everything.

If we had keyservers that didn't properly implement this new feature, then you have something to attack.  Users might believe that the feature actually works and act accordingly, only to find out that it doesn't actually work, and that it can be tricked into accepting keys it claims it won't.

> Without at all getting into the "flag" argument, do you feel keyservers should be verifying selfsigs before publication, or do you think they should remain "dumb"?  Both imply some problems, but your statement as to keyservers not doing crypto didn't seem to imply whether you're for or against it, and I'm curious.

I'm neither for it nor against it.  I'm for clearly specified and well designed features.  If one of those features requires crypto, then that's fine, and it becomes possible to weigh the pros and cons of adding crypto on the one side, and the benefit of the new feature on the other.

The cost of adding crypto is high.  The benefit of having the keyserver check self-sigs is minimal since the clients will have to do it all over again anyway.  I wouldn't do it just for that.  Once you've added crypto, though, a number of features that were previously impossible become possible (no-modify for one).

David