On 08/31/2013 02:53 PM, John Kelsey wrote:
I think it makes sense to separate out the user-level view of what happens.
True. I shouldn't have muddied up user-side view with notes about packet forwarding, mixing, cover traffic, and domain lookup, etc. Some users (I think) will want to know that much in general terms, in order to have some basis to evaluate/understand the security promises, but it's not part of the interface. Only the serious crypto wonks will want to know in more detail. {note: how strange! my spell checker thinks "crypto" is a typo, but has no problem with "wonks"!}
If something arrives in my inbox with a from address of nob...@nowhere.com, then I need to know that this means that's who it came from. If I mail something to nob...@nowhere.com, then I need to know that only the owner of that address will be able to read it.
As I consider it, I'm thinking even that promise needs to be amended to include the possibility of leaking from the recipient. For example email forwarding, unencrypted mail archives found by hackers, etc.
My intuition is that binding the security promises to email addresses instead of identities is the right way to proceed. I think this is something most people can understand, and more importantly it's somethingwe can do with existing technology and no One True Name Authority In The Sky handing out certs.
Eggs Ackley. I believe every user in the world is familiar at this point with the idea of an "email alias," and that the concept maps reasonably well to "holder of a key" for crypto purposes. To promise any more than that about "identity" requires centralized infrastructure that cannot really exist in a pure P2P system.
One side issue here is that this system's email address space needs to somehow coexist with the big wide internet's address space. It will really suck if someone else can get my gmail address n the secure system, but it will also be confusing if my inbox has a random assortment of secure and insecure emails, and I have to do some extra step to know which is which.
If you want to gateway secure mail into the same bucket with insecure mail, I guess you can do that; I would far rather have separate instances of mail clients that do not mix types. eg, this is Icedove/P2P, and this is Icedove/SMTP, and they are not expected to be able to interchange messages without some gateway. That said, all you need to gateway secure mail into an SMTP system is easy to construct. Consider if the peer mail system has an address structure like "name**domain": You have a machine with DNS/SMTP address like "secure.peermail. com" to reserve the name and provide bounce messages that prompt people to get a peer mail client and send a message in that client to "name**domain" for whatever address someone tried to reply to. Mail imported from the peer mail client with a name*domain mail format, could show in an SMTP client as "name**dom...@secure.peermail.com." Alternatively, or additionally, you could have a machine with an address like "insecure.peermail.com" that actually does protocol translation and forwards SMTP mail onto the secure network and vice versa, and allow peer mail users to choose which machine handles their SMTP-translated address. But this has the same problems as Lavabit and Silent Circle, which recently shut down under duress. Dual-protocol mail clients could use "name**domain" on the peer network directly. Mail imported from the SMTP network on a dual-protocol client or on a peer mail client could appear as "n...@address.com**INSECURE-SMTP" or similar, and on the dual-protocol client a direct reply would prompt use of the insecure protocol after a warning prompt. On a secure- protocol client it would simply prompt the user to use an insecure mail client, same as the bounce message on the other side. I see the Big Wide Internet's address space as a simple tool to implement it, not as a conflicting thing that needs reconciled. The "domain lookup" as I envision it would associate mail peer email addresses with a tuple of IPv6 address and public key. The public keys are stable; the IPv6 address may appear and disappear (and may be different each time) as the user connects and disconnects from the system. The presumption is that the mail peer daemon on the local machine sends a routing update message when starting up, and possibly another (deleting routing information) in an orderly shutdown. As stated earlier, the system makes no effort to actively hide the machine where an email address is located. It could be a machine designated to receive and keep mail for that address until it gets a "private address update" that tells it where to send the messages but which is not propagated; even in that case, the designated "maildrop" machine if not controlled by the holder of the address cannot be considered to hold any real secrets. Routing update messages propagate across the network of relevant domain servers, which check the sig on the update against the public key, update their table, and pass it on. Routing messages could propagate worldwide within minutes of a logon. Anybody holding a packet whose next hop is an email address which doesn't currently have an IPv6 address, simply holds it until the address appears or the packet expires. In a disorderly shutdown, other peers attempting to contact the IPv6 address still in the table should get a routing error from the protocol layer and update their own tables (only) to reflect the current absence of an IPv6 address. Peers should communicate only if their routing tables match (have matching hashes). In the event they don't, either one or both have one or more routing updates that the other does not, or one or both of them has detected a dropped connection that the other has not. In either event, the differences can be quickly and authoritatively resolved by identifying and forwarding the missing routing update/s, and by pinging the "dropped" machine/s to verify whether they're actually (or still) gone. Anyway; too much detail, too early. Need to consider more and plan less for now. Bear _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography