Subject: [Endymail] Hashes of key as addresses

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Aug 2014 19:23:20 -0400

Using hashes of keys as addresses is very powerful. There are
basically three types of address in such schemes:

1) traditional human readable

2) hash of key

3) Traditional human readable + hash of key.

So in PPE we use all three in different situations:

1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA

2) [email-masked]

3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?[email-masked]

We can apply the same approach with value to other situations. Lets
say Alice owns example.com. We can create a strong domain name in the
same way:

ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com

Note here that unlike in the PGP world where we generally use the hash
of the encryption key, PPE almost always uses the hash of a master key
that signs the encryption/authentication/etc key. This might have been
considered impractical in 1992 when machines were CPU limited but it
isn't a problem today.

Making this separation solves a lot of usability problems down the line.

Now obviously nobody is going to want to read out a strong email
address over the phone. But if we have the right discovery
infrastructure in place they don't need to.

And this is where TRANS/CT might come in (or something like it).
Because one of the things you would want to do with a freshly minted
key is to record the public part and some binding assertion in a
notary service. So it is natural to have a feature in the key manager
that allows you to say 'generate a key and register it with notary
xyz.com.'

I don't think I want to be registering my key with multiple notaries
as I think they should be talking to each other in the manner of
USENET of old. So one publication point should be enough.

But once the key is registered we have also created the raw material
that a key publication scheme might use.

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 28 Aug 2014 18:34:16 -0700

On Thu, Aug 28, 2014 at 07:23:20PM -0400, Phillip Hallam-Baker wrote:

[...]

> infrastructure in place they don't need to.

Can you please expand on this point? I think that if this is solved
then public key information would be far easier but that without it
we'll really struggle to communicate the secure form of an e-mail
address.

Thanks,

Leo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Aug 2014 22:02:31 -0400

> we'll really struggle to communicate the secure form of an e-mail

Well first off, this is obviously an area where there are likely to be
many ideas. So this is not something I want to weld into the client
right now. The proper place therefore for the capability would be in a
Web Service. In the past I worked on XKMS with Stephen and others. But
these days curly brackets are more fashionable than angle braces so I
think we want to go for a JSON service.

I have two specs defining an interface to the services:

1) OmniPublish: A Web service used by the key holder to manage their
keys. So this is the interface to the key publication mechanism,
notarization, certification, recovery and similar services.

2) OmniQuery: A Web service used by a party wanting to establish a
connection to an Internet end point which may be a Service or an
account.

These are both designed to support a broad spectrum of uses. But as it
turns out end to end email turns out to be the hardest security
problem to solve and so pretty much all the features are used.

[Links to all this stuff is on prismproof.org]

These specifications are designed to be as generic as possible and not
make constraining assumptions. But for there to be a system there
obviously needs to be some sort of infrastructure that takes the
information published though OmniPublish, processes it in some fashion
and delivers it on request in response to an OmniQuery.

As I said, I think there will be many ideas and this is a good thing.
But lets get one thing straight, lets make it so anyone who has a good
idea on how to join the two interfaces up just needs to write that
part of the code and not have to write their own email clients to test
it out.

The idea of OmniQuery is that it is a Web Service that acts like a
meta-directory on steroid. The OmniQuery broker can obtain the
information it returns in any way that makes sense.

So that said, here are some examples of how the two can be connected:

1) CA based certificate issue

CA issued email certs don't address every use case. In particular they
don't address use cases where the trust relationships are
non-hierarchical. But that does not change the fact that we have about
5 million users of S/MIME, most of whom work in organizations that are
hierarchical and issued certificates accordingly.

There have been many proposals for directories that map domains to
certificate servers. And an OmniQuery broker could acquire information
through those sources.

2) Certificate Transparency Notary Service

Lets say that a self-signed certificate is generated and published to
some party that enrolls it in a CT notary log and the log is public
and the OmniQuery service reads the log. The OmniQuery service now has
raw material that it could use to respond to key queries.

3) Combination of 1 and 2.

Lets say I set up a CT service for self signed email certs. Given that
Comodo offers free email certs, why not return them a freebie cert so
that they can use their S/MIME mail to sign mail?

Alternatively, won't a party running a log want to verify that a
request comes from the actual holder of the email address? If so they
will act like a CA even if they don't have all the process, audits
etc.

4) Web of Trust.

I really can't do justice to this here but the brief version is that
the PGP Web of Trust is a crock because it does not scale. But add in
a CT notary type service and a small number of CA validated links and
suddenly you get a Web of Trust that is stronger than either the PKIX
or Web of Trust model on its own.

[Been talking about this for several months BTW].

---

From: Michael Kjörling <[email-masked]>
Date: Fri, 29 Aug 2014 09:11:33 +0000

> ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com

Does this scheme not imply that everyone who wants to validate an
address, or know to where to pass a message given an address, needs to
either (a) query some form of central repository where all address
(hash)es are registered, or (b) have a local cache of all valid
address (hash)es?

Whether architectured in a distributed or centralized fashion, would
such a registry not become problematic? Lookups would be comparatively
costly (since even though it would be possible to split the storage,
you'd still be looking at what basically amounts to a sequential
search through some, likely relatively large, amount of data), if this
catches on it would soon grow very large, and imagine what spammers
would do if they could get their hands on a copy of that database.
Someone who is in control of such a database would have the potential
for massive (though not necessarily total) insight into who is
communicating with whom.

We know that breaches happen, even with the best of intentions (even
the NSA can't keep their data safe from breaches, as evidenced), so it
would appear that an architecture that creates such a valuable target
should be discouraged.

Initial mapping from a human-friendly (no matter what format) to a
hash (no matter what format) address would also seem to present the
problem of ensuring that you are mapping the correct human-friendly
address. You could, given an appropriate design, after that point be
certain that you are communicating with the _same_ person that you
started out communicating with, but could you be certain that you are
communicating with the _intended_ person (as opposed to someone else
by mistake, and as opposed to a MITMer)? If the human-friendly address
is enough to uniquely identify the recipient, then why would we need a
hash-based address scheme at all? If it isn't, then how is Joe R.
User, who wants to send a message securely to Alice Journalist,
expected to pick between "Alice Journalist, ACAIEA FONPAC 5AC6LFA
K4ACHC EAJWAHN VPAM4A COYPAO VAA" and "Alice Journalist, GJEIWO FMCPTE
9NM2GME X0AZZE XMDLWLF LLCP2K UHXHYM LHE", let alone between the first
and "Alice Journalist, ACAIEA F0NPAC 5AC6LFA K4ACHC EAJWAHN VPAM4A
COYPAO VAA"?

Compare SMTP where the originating SMTP server can do preliminary
validation (on the order of ensuring that the address is well-formed,
the domain exists and has a MX or address record) while the receiving
SMTP server does final address validation (local-part/hostname pair
exists and points to a valid mailbox) in an interactive dialog between
the servers, allowing reasonably good error reporting back to the
originating sender without any one entity having a complete address
registry. Since DNS is also highly distributed, no one entity even has
a complete list of all valid domain or fully qualified host names.

-- 
Michael Kjörling • https://michael.kjorling.se • [email-masked]
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 Aug 2014 09:37:22 -0400

> (hash)es are registered, or (b) have a local cache of all valid

No, it implies some mechanism for resolving the hashes. But that does
not need to be centralized.

Right now what the PPE proxy does is to strip out the domain component
of the email address and performs a HTTP WKS query for the
phingerprint block. So it would look up

http://example.com/.well-known/phb/ACAIEAFONPAC5AC6LFAK4ACHCEAJWAHNVPAM4ACOYPAOVAA

The dashes are removed as they have no semantic information. They are
purely for convenience.

> for massive (though not necessarily total) insight into who is

No, the system is no worse than DNS and that scales.

No sequential searches, its a hash table lookup and so extremely fast.
Should not require more than 6 lookups.

Each person's PHB is only a few KB so we are talking about 10 Tb or so
of data if everyone has a key. That is very manageable. It would need
a business model of course but so does every scheme that proposes
infrastructure.

> would appear that an architecture that creates such a valuable target

\The infrastructure is not trusted except for service.

An attacker cannot substitute an end-entity key because the key has to
be signed by the master key that matches the hash.

> and "Alice Journalist, ACAIEA F0NPAC 5AC6LFA K4ACHC EAJWAHN VPAM4A

That is the trust problem and there are various ways to address it.

The first step though is to have a set of addresses that can be used
to specify the trust relationship explicitly. Once we have that the
trust problem is reduced to achieving the mapping.

One way that works very well is to use QR codes in an in-person
meeting. Web of Trust never worked the way PhilZ wanted. But we didn't
carry supercomputers with cameras (aka smartphones) then.

> a complete list of all valid domain or fully qualified host names.

Well what you are doing is proposing the simplest solution to the
problem and showing why it is inadequate.

There does not need to be a central repository. There does not even
need to be global connectivity.