A conversation with dkg on p2p PGP sig swaps
From Guardian Project Wiki
Conversation with #debian-nyc on Thu 20 Oct 2011 03:55:52 PM EDT:
(05:29:46 PM) _hc: anyone here know anything about policy URLs in gpg?
(05:32:44 PM) dkg: yes :)
(05:35:35 PM) _hc: hey dkg
(05:35:39 PM) _hc: so we can chat now
(05:35:49 PM) _hc: you were in the corner last night and didn't come out ;)
(05:36:35 PM) _hc: I'm thinking about implementing a kind of p2p lsign swap, so a little less local than lsign and was wondering what respects the policy URL, like can I use a policy URL to prevent uploading a signature to keyservers?
(05:39:00 PM) dkg: no, a policy URL is strictly a human-to-human communication arrangement
(05:39:08 PM) dkg: i've never seen it used mechanistically
(05:39:57 PM) dkg: there are a couple guys on gnupg-users (who never seem to make it over to the IETF OpenPGP WG despite repeated suggestions) who seem to think that a robustly-defined ontology of certification policies could really take OpenPGP to the next level
(05:40:29 PM) dkg: my personal impression is that OpenPGP certifications are complicated/confusing enough as it is
(05:40:54 PM) dkg: and that asking people to internalize a potentially broad range of certification policies sounds difficult to me.
(05:41:01 PM) _hc: yes, it does
(05:41:25 PM) dkg: s/difficult/basically impossible/
(05:41:35 PM) _hc: a simple permission model could work
(05:41:42 PM) dkg: how do you mean?
(05:41:59 PM) _hc: something like UNIX u/g/o
(05:42:04 PM) _hc: u=local only
(05:42:14 PM) _hc: group = manual operations
(05:42:19 PM) _hc: other = keyserver
(05:43:03 PM) _hc: so say a sig is marked with g+r, it could be exported shared with someone manually, via a file, but not automatically uploaded to a keyserver
(05:43:14 PM) _hc: but 400 would only allow local use
(05:43:21 PM) _hc: or my understanding of lsign
(05:43:32 PM) _hc: can you export an lsign to a file?
(05:44:15 PM) _hc: then copy that file to someone else so they can import it
(05:45:27 PM) dkg: yes, you can do that.
(05:45:39 PM) dkg: are you aware that there is already a flag called "keyserver-no-modify" ?
(05:46:00 PM) dkg: and that while it is on almost every key by default these days, it is not respected by the keyservers or by any implementation?
(05:46:01 PM) _hc: hehe, like you said, the spec is large ;)
(05:46:02 PM) _hc: so no
(05:46:23 PM) _hc: well, that's not good
(05:46:23 PM) dkg: the goal of the flag is to make it so that "somehow" the keyservers only accept updates approved by the keyholder.
(05:46:57 PM) _hc: ah, ok, that would be very nice
(05:46:58 PM) dkg: but no such mechanism has ever been implemented (possibly never even proposed, though it seems like there's a pretty straightforward approach to me if someone wanted to implement it)
(05:47:18 PM) _hc: what I'm thinking about it more like a p2p sig swap
(05:47:30 PM) _hc: without keys going up to the keyserver ever
(05:47:36 PM) _hc: so lsign with p2p transfer
(05:47:51 PM) dkg: what specifically would you be transferring?
(05:47:55 PM) dkg: Alice and Bob meet up
(05:48:01 PM) dkg: they exchange keys
(05:48:02 PM) _hc: or maybe not even p2p, like person to person, point to point really
(05:48:12 PM) _hc: good old Alice and Bob
(05:48:41 PM) _hc: Alice and Bob exchange lsigns so that they can get trust paths to other people
(05:48:45 PM) dkg: under the caff regime (if you appear to be certifying an e-mail address) it makes sense for alice to send her certifications to bob's e-mail account
(05:48:58 PM) dkg: (whether or not the certifications are "exportable")
(05:49:29 PM) dkg: and alice's certification would be encrypted to bob's key anyway
(05:49:33 PM) dkg: so only bob could import it.
(05:49:37 PM) dkg: all of that is already in place
(05:49:42 PM) dkg: so i assume you're talking about something else
(05:49:59 PM) dkg: like the ability for alice and bob to p2p swap certifications on their own keys from charlie
(05:50:07 PM) _hc: hmm, no that's about right, but easy to do
(05:50:10 PM) _hc: and manage
(05:50:17 PM) _hc: not having to see and deal with the emails
(05:50:26 PM) _hc: and caff is not easy to use
(05:50:31 PM) _hc: unless you are a DD
(05:50:31 PM) dkg: agreed about caff
(05:50:48 PM) dkg: but if you don't deal with e-mails, then you aren't actually verifying the e-mail address
(05:50:57 PM) dkg: unless you already know their e-mail address of course
(05:51:07 PM) _hc: it would be nice to have some kind of enforcement preventing sigs from being uploaded to keyservers
(05:51:18 PM) dkg: that's what non-exportable certification is for
(05:51:29 PM) dkg: that part *is* implemented, honored, and respected.
(05:51:39 PM) dkg: but it's on a per-certification basis
(05:51:42 PM) dkg: not a per-key basis.
(05:52:08 PM) dkg: i suppose one thing you could do is to set the non-exportable flag on your own self-sig
(05:52:22 PM) dkg: then the keyservers should reject it in the first place.
(05:53:09 PM) dkg: note that avoiding keyservers like this might solve some problems (i'm not sure what problem you're trying to solve, though i'd be interested in hearing details), but it introduces other problems
(05:53:42 PM) dkg: you should make sure that the folks you encourage to avoid keyservers like this understand what they're losing by not permitting updates to the keyservers
(05:55:07 PM) _hc: the public social graph problem is what I'm thinking about
(05:55:43 PM) _hc: I'm thinking of using the public keyservers for keys and revokations
(05:55:50 PM) _hc: but then only having sigs local
(05:55:50 PM) dkg: it's not a social graph, unless you're foolish enough to only certify your close friends' keys
(05:56:13 PM) dkg: and frankly, if you're exchanging e-mail, that social graph is capturable in other ways as well.
(05:56:33 PM) dkg: though i admit that harvesting from keyservers is easier than intercepting mail.
(05:56:41 PM) _hc: yes, but its not easily downloadable by anyone
(05:56:44 PM) _hc: like from a keyserver
(05:57:18 PM) dkg: i'm glad you're willing to use the keyservers for revocations
(05:57:54 PM) dkg: i'm a bit puzzled by what piece of the puzzle you think is currently lacking, though, for your proposal.
(05:58:13 PM) dkg: i don't see how a "permission model" would affect things.
(05:58:34 PM) dkg: if anyone posts a public key to the keyservers, anyone can fetch and certify that key.
(05:58:51 PM) dkg: that's sort of the nature of the beast.
(05:59:36 PM) _hc: the perm model thing was a side note related to the complicated policy proposals
(05:59:54 PM) dkg: furthermore, even if you could somehow prohibit anyone from making a public certification, i don't know what good it would do to put your key on the public keyservers in the first place
(06:00:11 PM) dkg: since it wouldn't be certified by anyone
(06:00:31 PM) dkg: and therefore there would be no reason to trust it over any other key with the same user ID attached.
(06:05:23 PM) _hc: that's where the p2p sig transfer comes in
(06:05:30 PM) _hc: the keyserver would just be for revokations
(06:07:04 PM) _hc: caff should really pop up the emails in the mail client
(06:07:18 PM) _hc: using the mail server is flaky with laptops...
(06:07:39 PM) _hc: (side note)
(06:13:08 PM) dkg: earlier you said the keyserver would be for keys and revocations
(06:13:17 PM) dkg: now yu're saying it's just for revocations.
(06:13:30 PM) dkg: i think your latter stance makes more sense if you really want to pursue this.
(06:13:32 PM) _hc: revokatiobs are the most useful
(06:13:36 PM) dkg: yep
(06:14:01 PM) _hc: I guess might as well keep the keys off of the keyserver
(06:14:21 PM) _hc: since using encryption is a flag in many places in the world
(06:14:27 PM) dkg: i don't think an key without any certifications on it is much use to anyone
(06:14:34 PM) dkg: at best, it's a minor convenience
(06:14:37 PM) _hc: right
(06:14:40 PM) dkg: at worst, it's a phishing attack
(06:14:54 PM) _hc: the sigs get transferred by person-to-person exchanges
(06:15:09 PM) dkg: but to be clear: i don't think that avoiding the keyservers is a good tradeoff for most people.
(06:15:18 PM) _hc: I'm not thinking about most people
(06:15:31 PM) _hc: think like syrian activist
(06:15:34 PM) dkg: you need to think through what specifically you expect to see transferred during the person-to-person exchanges.
(06:15:55 PM) dkg: and what the implications are -- there are different implications if different objects are getting transferred.
(06:16:01 PM) _hc: I sign their key and send them other people sigs on my key
(06:16:45 PM) dkg: (can you call them certs or certifications? i think it's useful to distinguish between signatures-over-data (sigs) and signatures-over-identity-claims (certs))
(06:16:56 PM) dkg: so alice and bob meet up
(06:17:01 PM) _hc: k
(06:17:02 PM) dkg: they do their in-person exchange
(06:17:35 PM) dkg: now alice has a copy of bob's OpenPGP certificate, along with N non-exportable certifications that this is in fact Bob's key.
(06:17:43 PM) _hc: yes
(06:18:03 PM) dkg: 0) how does bob decide which certs he wants to give to alice in this p2p exchange?
(06:18:13 PM) dkg: 1) how does alice protect that information?
(06:18:17 PM) _hc: well, I think to be simple, it would send all certs
(06:18:48 PM) dkg: 2) are they willing to exchange the certificates of third parties as well?
(06:19:00 PM) dkg: (e.g. should bob give alice charlie's key during this same exchange?)
(06:19:27 PM) _hc: hmm, hadn't thought about that much, was mostly thinking about certs
(06:19:36 PM) _hc: it probably makes sense to sync up keyrings
(06:19:50 PM) _hc: but that's probably too much info to share by default
(06:19:56 PM) dkg: if alice has never met with charlie before, how do you expect alice to communicate securely with charlie ?
(06:20:06 PM) _hc: there could be two modes, sync all certs on my key
(06:20:09 PM) _hc: and sync keyrings
(06:20:32 PM) dkg: 3) now let's assume that alice gets taken away by the secret police, and they use rubber-hose cryptanalysis to get the contents of her hard drive.
(06:20:46 PM) dkg: she publishes her off-site revocation certificate immediately so they can't use her key
(06:20:50 PM) _hc: evreryone is fucked
(06:21:00 PM) dkg: but yeah: everyone is fucked.
(06:21:07 PM) dkg: so what are you gaining here?
(06:21:19 PM) _hc: they can't find this info easily on the net
(06:21:24 PM) _hc: they have to find the actual people
(06:21:31 PM) dkg: they have to find one actual person
(06:21:42 PM) dkg: whereas, if everyone has a key already in the first place
(06:21:58 PM) dkg: and people aren't so foolish as to only certify the keys of their close-and-trusted comrades
(06:22:33 PM) dkg: then there's nothing to search for, because the *nature* of the human relationships (other than "i have at one time confirmed that this key belongs to this person") is not present in the keyservers.
(06:22:48 PM) _hc: the software isn't really going to solve the torture problem
(06:22:58 PM) dkg: i agree
(06:23:05 PM) _hc: the person can just talk about who they communicate with
(06:23:10 PM) _hc: no matter how good the software
(06:23:35 PM) dkg: the only thing i think this proposal is going to do is to encourage people to avoid building out a network of public identity
(06:23:41 PM) dkg: (which may itself be pseudonymous)
(06:23:56 PM) dkg: andn i think that a network of public identity itself is a useful anti-repressive tool
(06:23:59 PM) _hc: yes, that's the point
(06:24:02 PM) dkg: because it makes it easier to communicate securely.
(06:24:06 PM) _hc: avoid building a public network
(06:24:17 PM) dkg: it's not a social graph
(06:24:30 PM) dkg: these are just confirmations of identity.
(06:24:31 PM) _hc: close enough
(06:24:40 PM) dkg: i beg to differ
(06:24:46 PM) _hc: I don't think the syrian police care
(06:24:50 PM) dkg: especially in the case of the syrian police
(06:25:03 PM) dkg: since they're actually in a position to do traffic analysis
(06:25:10 PM) _hc: showing up as associated with someone they deem bad is all it takes
(06:25:33 PM) dkg: traffic analysis reveals *much* more than claims of identity
(06:25:42 PM) _hc: saying "I was just confirming their identity" won't mean anything
(06:26:14 PM) _hc: if we are talking about email, HTTPS and IMAP-TLS are prety easy to do
(06:26:32 PM) _hc: SMTP TLS
(06:26:55 PM) dkg: heh. do you know how many SMTP providers do hard failures on TLS certificate verification failure?
(06:27:17 PM) _hc: yes, its inpefect
(06:27:22 PM) dkg: indeed
(06:28:39 PM) dkg: anyway, i think such a project could in fact be useful in some limited cases, but i've also seen resistance to public identification actively cripple attempts to make it easier to use crypto in general.
(06:28:49 PM) dkg: i think this is a very real tradeoff, unfortunately.
(06:28:53 PM) _hc: I agree
(06:29:09 PM) _hc: but for this project, having the certs public is a real risk
(06:29:10 PM) dkg: i think we have less use of secure communications as a result :/
(06:29:34 PM) _hc: the use case here is places where just the use of encryption is a flag that can get you in trouble
(06:29:38 PM) dkg: anyway, i don't think there's anything missing in the infrastructure for what you're proposing.
(06:29:46 PM) _hc: good to hear
(06:30:06 PM) dkg: if you find yourself stumbling on something, feel free to ask me about it.
(06:30:13 PM) _hc: know any java impls that can do it? ;)
(06:30:20 PM) dkg: i have no idea
(06:30:30 PM) dkg: i don't even know how to use a library in java, as i discovered the other day.
(06:30:37 PM) _hc: I might be implementing some of gpg's features in Java... sigh
(06:31:03 PM) dkg: why java? do i want to know?
(06:32:16 PM) _hc: Android and phones
(06:33:24 PM) dkg: speaking of imperfect security :/
(06:33:43 PM) dkg: _hc: are you on the freedombox-discuss trainwreck^W^W^W^W mailing list?
(06:33:53 PM) _hc: no, I'm not
(06:34:01 PM) _hc: just too overcommitted
(06:34:02 PM) _hc: why?
(06:34:35 PM) dkg: you should read the recent posts there from Timur Mehrvarz
(06:34:59 PM) _hc: why's that?
(06:35:09 PM) dkg: in particular, you might be interested in timur.mobi/anymime-ksp/
(06:35:13 PM) dkg: in particular, you might be interested in <a href="http://timur.mobi/anymime-ksp/">http://timur.mobi/anymime-ksp/</a>
(06:35:31 PM) dkg: bluetooth and/or NFC key transfer
(06:35:43 PM) dkg: Timur seems like a reasonable guy
(06:35:50 PM) dkg: and he's got a lot implemented already
(06:36:00 PM) dkg: and he was fairly responsive to concerns about security
(06:36:09 PM) gdl: Neat!
(06:36:10 PM) _hc: ah, cool
(06:37:22 PM) dkg: i can't claim it's perfect (i've got a lot of issues/concerns with bluetooth, and i can't say i really trust it for private or integrity-checked communications) but he's given some of the best arguments for it that i've seen
(06:37:26 PM) dkg: he's clearly thought about it.
(06:37:55 PM) _hc: ok, gotta run, thanks for that discussion
(06:37:58 PM) _hc: very helpful
(06:38:07 PM) _hc: I'm sure we'll talk more on this topic :)
(06:38:27 PM) dkg: sounds good
(06:38:28 PM) gdl: _hc: What is it you need out of GPG that APG doesn't provide?
(06:40:15 PM) _hc: gdl: * no method for uploading personal public key
(06:40:15 PM) _hc: * no method for signing other people's keys
(06:40:15 PM) _hc: * no method to view signatures on a key