On Tue, Jan 6, 2015 at 4:08 AM, Michael Rogers <[email protected]> wrote: > > On 06/01/15 00:18, Trevor Perrin wrote: >> (e) >> Changing this "identity info" may be costly for Bob (telling all >> his correspondents his info changed, changing a bunch of >> registrations, getting new certificates, printing new business >> cards, etc). >> (f) >> Alice can lookup Bob's shorter-lived and/or >> one-time "prekeys" from some service (either centralized, or hosted >> by Bob's provider) which is not trusted for confidentiality or >> authentication. [...] > > Let's take the costs you've outlined in (e) one at a time. > > Correspondents: Bob's correspondents are automatically introduced to > the new device by his existing devices. No effort for Bob.
I think you're saying that when Bob gets a new device and introduces its public key to one of his existing devices, the existing device could send a message to all of Bob's correspondents informing them of the new device? That seems worse than the other options. What if Bob's device doesn't remember every correspondent? What if Bob has cleared history, or isn't aware of everyone who has cached his "identity info"? What if Bob has ten thousand people he's ever corresponded with? What if some of them have changed their address, or are temporarily unreachable, or the message gets lost for some other reason? My argument is that instead of updating everyone that might be remembering your identity info, it's easier to leave that info unchanged and just sign the new device's key, or synchronize the existing private key to the new device. > Registrations: We've left open the question of where Bob's info might > be registered (servers, DHT, etc), but again, any of Bob's registered > devices can automatically authenticate the registration of the new > device. No effort for Bob. > > Certificates: I'm not sure what you have in mind here. If you're > imagining that this will tie into some existing hierarchical PKI then > I guess it does make sense to continue the hierarchy and have a master > key that certifies device keys. > > Business cards: You know what I think about this use case. :-) We could work through every possible infrastructure you might use your public key with, but I think the general point stands: the less often you change your public-key / fingerprint and have to redistribute it, the better. Tackling this another way: You're assuming Bob informs his existing device of the new device's public key. At this point, it's easy for the existing device to sign the new device's key, or encrypt the master private key to the new device. Since there's little cost to these, why not do one of them? Do you feel there's some problem with signing device keys, or synchronizing the master private key? - Side note: I'm arguing here that we should keep a user's "identity info" stable when adding devices. But with David, I've argued it's not worth supporting revocation that would keep this info stable while revoking a device key. The reason is I think the former is easy (sign or encrypt to the new device's public key), whereas I think revocation is much more complicated and problematic. >> The most practical approaches are probably either synchronizing >> the identity key between devices, or using it to sign device keys. >> Either way, adding a new device might increase communication in >> (f), since Alice might have to retrieve additional device-specific >> prekeys, and/or signed device keys. But adding a device would not >> incur the costs in (e), which is more important. > > Why is it more important? Presumably (f) happens more often than (e). In systems like TextSecure or Pond, Alice has to contact Bob's server to deliver the message anyways. So having Bob's server tell Alice "oh, Bob has a new device, here's its signed key and prekeys" when she goes to deliver a message is easy. >>>> If you require interaction with one device to learn about >>>> others, you lose "asynchronousness", and I'm not sure what you >>>> gain. If you're using different device keys not signed by a >>>> single key, you lose fingerprint-ability. >>> >>> The process by which a device introduces a contact to its >>> owner's other devices is asynchronous. >> >> That's not asynchronous enough for email / text-messaging though >> (b, c). > > Sorry, I don't understand what you mean by "not asynchronous enough". > It could literally operate over carrier pigeons. I thought you were talking about an interactive communication with the introducing device. Now I think I understand you're talking about the introducing device just sending a message to correspondents. That may be better, but see issues above. >> I probably depends on your assumptions / use cases. If you only >> establish connections face-to-face that can be authenticated via >> device pairing (QR codes, SAS, etc), then you may be right that >> having a single identity public key doesn't get you much. > > I'm not assuming that all connections will be face to face. Face to > face connections are only required (a) to add a contact and > immediately know you're using valid key material for them, or (b) to > validate key material you've been using for a contact who wasn't added > face to face. > > If we assume there's no totally trustworthy third party, and no > self-authenticating channel other than face to face, then these > operations need to be face to face for any of the options we've > considered, don't they? I don't agree with those assumptions. Or at least, there's a huge difference between: - a single third party that everyone trusts for everything - context-specific third parties that particular Alices trust to inform them about particular Bobs I agree the former doesn't exist, but the latter ones do, and those are channels I want to send "identity info" like fingerprints through. Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
