<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 August 2013 21:29, Perry E. Metzger <span dir="ltr"><<a href="mailto:perry@piermont.com" target="_blank">perry@piermont.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[Disclaimer: very little in this seems deeply new, I'm just<br>

mixing it up in a slightly different way. The fairly simple idea I'm<br>
about to discuss has germs in things like SPKI, Certificate<br>
Transparency, the Perspectives project, SSH, and indeed dozens of<br>
other things. I think I even suggested a version of this exact idea<br>
several times in the past, and others may have as well. I'm not going<br>
to pretend to make claims of real originality here, I'm more<br>
interested in thinking about how to get such things quite widely<br>
deployed, though it would be cool to hear about prior art just in case<br>
I decide to publish a tech report.]<br>
<br>
One element required to get essentially all messaging on the<br>
Internet end to end encrypted is a good way to find out what people's<br>
keys are.<br>
<br>
If I meet someone at a reception at a security conference, they might<br>
scrawl their email address ("<a href="mailto:alice@example.org">alice@example.org</a>") for me on a cocktail<br>
napkin.<br>
<br>
I'd like to be able to then write to them, say to discuss their<br>
exciting new work on evading censorship of mass releases of stolen<br>
government documents using genetically engineered fungal spores to<br>
disseminate the information in the atmosphere worldwide.<br>
<br>
However, in our new "everything is always encrypted" world, I'll be<br>
needing their encryption key, and no one can remember something as<br>
long as that.<br>
<br>
So, how do I translate "<a href="mailto:alice@example.org">alice@example.org</a>" into a key?<br>
<br>
Now, the PGP web-of-trust model, which I think is broken, would have<br>
said "check a key server, see if there's a reasonable trust path<br>
between you and Alice."<br>
<br>
I have an alternative suggestion.<br>
<br>
Say that we have a bunch of (only vaguely) trustworthy organizations<br>
out in the world. (They can use crypto based log protocols of various<br>
kinds to make sure you don't _really_ need to trust them, but for the<br>
moment that part doesn't matter.)<br>
<br>
Say that Alice, at some point in the past, sent an email message,<br>
signed in her own key, to such an organization's key server, saying in<br>
effect "this is <a href="mailto:alice@example.org">alice@example.org</a>'s key".<br>
<br>
At intervals, the trustworthy organization (and others like it) can<br>
send out email messages to Alice, encrypted in said key, saying "Hi<br>
there! Please reply with a message containing this magic cookie,<br>
encrypted in our key, signed in yours."<br>
<br>
If a third party needing the key for <a href="mailto:alice@example.org">alice@example.org</a> queries the<br>
vaguely trusted server, it will then give them information like "For<br>
the past six years, we've been sending <a href="mailto:alice@example.org">alice@example.org</a> emails every<br>
couple of weeks asking her to reply to demonstrate she controls a<br>
particular public key, and she always has -- new keys have always been<br>
signed in the old one, too. Here's a log, including various sorts of<br>
widely witnessed events and hash chains so that if we were lying about<br>
this we had to be planning to lie about it for a very long time."<br>
<br>
Now of course, in the real world, who wants to go through the effort<br>
of hand replying to query messages to establish a key over time?<br>
Instead, Alice has some actually trusted software running on her<br>
computer at home.<br>
<br>
She can either leave it to automatically do IMAP queries against her<br>
mailbox (which could even be GMail or what have you) and reply on her<br>
behalf, or it could ask her to unlock her key while she's at home in<br>
the morning having her coffee. However, I think the former is actually<br>
preferable. We'd rather have an imperfect system that is effortless to<br>
use but can be bypassed by physically breaking in to someone's home.<br>
(After all if you did that you probably can bug Alice's hardware<br>
anyway.)<br>
<br>
Alice probably also needs to make sure someone isn't spoofing her<br>
replies by accessing her IMAP box and replying for her (using a key<br>
known to the attacker but presumably not to Alice) and then deleting<br>
the query, but the mere absence of periodic pings from the trusted<br>
party may be enough to create suspicion, as might doing one's own<br>
queries against the trusted parties and noticing that the key isn't<br>
your own.<br>
<br>
Presumably, of course, there should be a bunch of such servers out<br>
there -- not so many that the traffic becomes overwhelming, but not so<br>
few that it is particularly feasible to take the system off the<br>
air. (One can speculate about distributed versions of such systems as<br>
well -- that's not today's topic.)<br>
<br>
So, this system has a bunch of advantages:<br>
<br>
1) It doesn't require that someone associated with administrators of<br>
the domain name you're using for email has to cooperate with deploying<br>
your key distribution solution. Alice doesn't need her managers to agree<br>
to let her use the system -- her organization doesn't even need to<br>
know she's turned it on. Yet, it also doesn't allow just anyone to<br>
claim to be <a href="mailto:alice@example.org">alice@example.org</a> -- to put in a key, you have to show you<br>
can receive and reply to emails sent to the mailbox.<br>
<br>
2) You know that, if anyone is impersonating Alice, they had to have<br>
been planning it for a while. In general, this is probably "good<br>
enough" for a very large number of purposes, and much better than a<br>
perfect system that no one ever uses.<br>
<br>
You can always trade a key hash with Alice personally, of course, and<br>
if you do, perhaps she sets her software to personally alert you to<br>
key refresh events and such (which we'll gloss over.) However, you<br>
don't *have* to do it that way -- the system makes it possible to get<br>
a reasonable amount of de facto trust without needing you to make many<br>
decisions that ordinary people have trouble making, too. None of this<br>
"I know this is Charlie's real key, but do I think Charlie is<br>
trustworthy to sign Alice's key, or would he have been sloppy"<br>
business that PGP imposes.<br>
<br>
(We can gloss over details like a protocol for Alice to update her key<br>
at intervals, or to make repeated claims that she was stupid and lost<br>
her key and needed to generate a new one, or what have you. I think<br>
they're solvable, and I don't want to clog up the gist of the idea<br>
with them.)<br>
<br>
3) The system can be extremely lightweight to implement.<br></blockquote><div><br></div><div>Not sure about _extremely_, but I certainly agree it should be relatively straightforward. And since I have an interest in the "Here's a log, including various sorts of widely witnessed events and hash chains so that if we were lying about this we had to be planning to lie about it for a very long time." (not sure I agree about that last part, btw), I hereby volunteer to implement that part if there are people willing to implement the rest...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Disadvantages are obvious. It isn't "perfect" in that mostly, it is<br>
just depending on temporal continuity and widely witnessed information<br>
to discourage forgery. On the other hand, that's a damn sight better<br>
than a universal key management system that doesn't exist.<br>
<br>
A few more notes:<br>
<br>
First, I said nothing about "certificates". I've contended for a very<br>
long time that I'm not sure what the function of the things really<br>
is. What I want in the real world is the sort of attestation of long<br>
term use that got discussed above. This system could use X.509 certs<br>
as a pure data format, of course, or PGP keys, or raw integers in the<br>
SSH style. Who cares.<br>
<br>
Second, I've said nothing really about what such keys could be used<br>
for. I'm thinking along the lines of next generation secure IM and<br>
Email systems, but really, such things could be used for anything. If<br>
people particularly insist on having separate keys for different<br>
purposes, they'll need to arrange to store some sort of label along<br>
with each of several keys in the key servers, of course, and they'll<br>
need to arrange to periodically sign round trips for all those<br>
keys. Personally, I think this is probably more trouble than it is<br>
worth, but I could be persuaded.<br>
<br>
Third, presumably one wants a means to query such databases that<br>
doesn't allow traffic analysis. Mix networks including Tor are<br>
probably the answer on that. Without such a mechanism, listening in on<br>
the query traffic becomes a very good way to trace out social<br>
networks.<br>
<span class=""><font color="#888888"><br>
Perry<br>
--<br>
Perry E. Metzger                <a href="mailto:perry@piermont.com">perry@piermont.com</a><br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</font></span></blockquote></div><br></div></div>