[Cryptography] Functional specification for email client?

Ray Dillinger bear at sonic.net
Sun Sep 1 13:14:25 EDT 2013


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 nobody at nowhere.com,
> then I need to know that this means that's who it came from.  If I mail
> something to nobody at 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**domain at 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 "name at 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



More information about the cryptography mailing list