Re: [Cryptography] Functional specification for email client?
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
Re: [Cryptography] Functional specification for email client?
Some comments, only. On 30/08/13 11:11 AM, Ray Dillinger wrote: Okay... User-side spec: 1. An email address is a short string freely chosen by the email user. It is subject to the constraint that it must not match anyone else's email address, but may (and should) be pronounceable in ordinary language and writable with the same character set that the user uses for writing. They require extension with a domain as current email addresses do, but not a domain name in the IETF sense; just a chosen disambiguator (from a finite set of a million or so) to make name collisions less of a problem. 2. An email user may have more than one email address. In fact s/he can make up more email addresses at any time. He or she may choose to associate a tagline -- name, handle, slogan or whatever -- with the address. An email user may have one or more identities... (confusion between email addresses, keys, chat handles, etc). 3. When an email user gets an email, s/he is absolutely sure that it comes from the person who holds the email address listed in its from line. S/he may or may not have any clue who that person is. S/he is also sure that no one else has seen the contents of the email. The tagline and email address are listed in the from: line. This requirement is troubling, and it has bedevilled many systems because it has artificially locked them into perfect traffic analysis, low key agility, poor economics, and messy identity semantics. It typically is an assumption of the email providers that an email address must have a certificate, and this allows the certificate to be 'checked' against the email address. But it is not necessary nor particularly effective. A better requirement might be worded: When a user receives an email, she is sure that it comes from the stated identity as found in the address book. The stated identity may not be related to the from line. 4. A user has an address book. The address book can be viewed as a whole or as seen by just one of the user's email addresses. IOW, if you have an email address that you use for your secret society and a different email address that you use for your job, you can choose to be one or the other and your address book will reflect only the contacts that you have seen from that address or have been visible to under that address. 5. A mail client observes all email addresses that go through it. all identities (email addresses and/or keys)... When a user receives mail from someone who has not directly sent them mail before, the client opens a visible entry in the address book and makes available a record of previous less-direct contacts with that address, for example from posts to mailing lists, from CC: lists on emails, etc. The client also makes visible a list of possible contact sources; places where the correspondent may have seen the address s/he's writing to. However, often enough, especially with cases where it's a scribbled on a napkin address, the client just won't know. 6. When a user sends mail, s/he knows that no one other than the holder of the address/es s/he's sending it to will see the body of the mail, and also that the recipient will be able to verify absolutely that the mail did in fact come from the holder of the user's address. This needs to nailed down, otherwise the system falls into the abyss of digital signatures. What this means (at a lower level) is that every mail is digitally signed by the sender. It needs to be stated that the signature of the sender's key means that the message came from the sender's key, and not anything else. Especially, it is not a signed contract, not a non-repudiable bla bla, and is not even a proof that the person sent the message (without significant other support). That is, the digsig is a low-level protocol tool, not a legal digital signature. Also, to bed in a complete understanding, a separate requirement 6.b should be added for a second signing process using separate signing keys following the notions expressed in (eg) EU digital signature directive (eg) OpenPGP cleartext signing. However, this should be clearly stated as optional, as such digital signatures are fraught, and if not optional, the system will fail to be implemented and be accepted. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Functional specification for email client?
I think it makes sense to separate out the user-level view of what happens (the first five or six points) from how it's implemented (the last few points, and any other implementation discussions). In order for security to be usable, the user needs to know what he is being promised by the security mechanisms--not which digital signature scheme is being used or whether decoy messages are sent to frustrate traffic analysis. 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. I need to know that nobody should be able to know with whom I'm communicating. But I don't need to know about keys, digital signatures, mix nets, etc. That's what I want to know as a cryptographer, but as a user, I just want to know what the security system is promising and how reliable its promises are. 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 something we can do with existing technology and no One True Name Authority In The Sky handing out certs. 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. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Functional specification for email client?
Okay... User-side spec: 1. An email address is a short string freely chosen by the email user. It is subject to the constraint that it must not match anyone else's email address, but may (and should) be pronounceable in ordinary language and writable with the same character set that the user uses for writing. They require extension with a domain as current email addresses do, but not a domain name in the IETF sense; just a chosen disambiguator (from a finite set of a million or so) to make name collisions less of a problem. 2. An email user may have more than one email address. In fact s/he can make up more email addresses at any time. He or she may choose to associate a tagline -- name, handle, slogan or whatever -- with the address. 3. When an email user gets an email, s/he is absolutely sure that it comes from the person who holds the email address listed in its from line. S/he may or may not have any clue who that person is. S/he is also sure that no one else has seen the contents of the email. The tagline and email address are listed in the from: line. 4. A user has an address book. The address book can be viewed as a whole or as seen by just one of the user's email addresses. IOW, if you have an email address that you use for your secret society and a different email address that you use for your job, you can choose to be one or the other and your address book will reflect only the contacts that you have seen from that address or have been visible to under that address. 5. A mail client observes all email addresses that go through it. When a user receives mail from someone who has not directly sent them mail before, the client opens a visible entry in the address book and makes available a record of previous less-direct contacts with that address, for example from posts to mailing lists, from CC: lists on emails, etc. The client also makes visible a list of possible contact sources; places where the correspondent may have seen the address s/he's writing to. However, often enough, especially with cases where it's a scribbled on a napkin address, the client just won't know. 6. When a user sends mail, s/he knows that no one other than the holder of the address/es s/he's sending it to will see the body of the mail, and also that the recipient will be able to verify absolutely that the mail did in fact come from the holder of the user's address. 7. Routing information once obtained for a given domain is maintained locally. This means routing information for each email address is public knowledge, but also means that no one can tell from your address queries who specifically your correspondents are more precisely than knowing which domains they are in. This also means that other users may obtain routing information for that domain from you. You can update your routing information (ie, set the system to route messages for your address to the network location where you actually are) at any time, via a message propagated across all peers serving the domain of that address. Also, your client keeps your addresses alive by periodically sending out a message that is propagated across all server peers for that domain. This happens at intervals you set (a few months to ten years) when you create the email address. If that interval goes by without a keep-alive or a routing information update, the servers will drop the address. 8. Emails are mixed on your machine locally, then sent out onto the network. The mixing means creating packets of a uniform size, planning a route for each, encrypting them once for each 'hop' on the route, and sending them. Routing is constrained to average less than ten 'hops'. The packet size should be selected so most text emails are one packet or less. Larger messages will be sent as a set of packets and reassembled at destination. Packets will be released at a rate of one every few seconds; very large file attachments may take days to send and are discouraged. 9. Your machine, while connected, is collecting your email. It is also in the business of packet forwarding: ie, it gets a packet, decrypts it, reads the next hop, waits some random number of seconds, and sends it to the next hop. 10. Finally, your mail client will occasionally create one or more packets and send them via some randomly selected route to another point on the network, where they will be received and ignored. It will do this just about as often as it sends original content-bearing packets, and about five percent as often as it forwards packets. This generates 'cover traffic' equal to about three quarters of the total network volume. Generation and receipt of cover traffic is completely invisible to the user.
Re: [Cryptography] Functional specification for email client?
On Fri, 30 Aug 2013, Ray Dillinger wrote: 3. When an email user gets an email, s/he is absolutely sure that it comes from the person who holds the email address listed in its from line. S/he may or may not have any clue who that person is. S/he is also sure that no one else has seen the contents of the email. This probably needs amending to deal with messages addressed to multiple recipients (either cc:, bcc:, or simply multiple to: addresses). -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Functional specification for email client?
On 08/30/2013 01:52 PM, Jonathan Thornburg wrote: On Fri, 30 Aug 2013, Ray Dillinger wrote: 3. When an email user gets an email, s/he is absolutely sure that it comes from the person who holds the email address listed in its from line. S/he may or may not have any clue who that person is. S/he is also sure that no one else has seen the contents of the email. This probably needs amending to deal with messages addressed to multiple recipients (either cc:, bcc:, or simply multiple to: addresses). Right. More generally, I was hoping for feedback as to whether this is a design useful to and usable by ordinary people. It's fairly straightforwardly implementable as a fully distributed system, given the notion that routing information includes public key. The only slightly tricky issue is maintaining the coherence of the per-domain routing databases among mutually suspicious clients, and there are existing techniques for that. It's also compatible with current standards for email payloads, so existing infrastructure can easily be adapted; in the protocol stack, it looks like any other MTA. It can also fairly easily gateway to SMTP, but is not dependent on it. Bear ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
