PKA updates

[Werner Koch]

On Wed, 25 Feb 2015 23:55, hanno at hboeck.de said:

> I thought about this. A DNS record that points to a key that has to be
> grabbed elsewhere.

Right, it would also be possible to put the key into the DNS proper
(certtype PGP) but that won't fit into an UDP packet and thus it will be
a bit slower.  Further, for any key updates you need to update that copy
of the key and thus you depend on the admin of the zone.  The
--auto-key-locate method "cert" allows this anyway (need to store the
key under its fingerprint, but that is desirable anyway) and can be used
in addition to IPGP.

> I wonder: Why this DNS middleman? It's kinda the worst one, because
> it's insecure by design. (if anyone cries "DNSSEC" - I'll get to that)

For a very simple reason.  If you want to send a mail to foo at example.org
you or your smarthost need to lookup the MX for example.org anyway.
Thus a DNS retrieval is required in any case and an addition IPGP fetch
won't harm.

Sure, this reveals the local-part of the address (the hash is no
protection against this) but the proposal is not about hiding meta data
but about an easy way to find a key for an arbitray mail address.

By the time we have an ubiquitous anonymous naming system, the very same
method can be used with such a system and would solve the meta data
leakage instantly.  And given that such a system will anyway be a part
of a fully anonymized net the entire met data problem will be solved.

Instead of sending a DNS request from the local client, it might also be
possible to extend IMAP to have the provider lookup the fingerint and
key for you.  This somewhat mitigates the leakage of the local-part.

> Why not use https directly? It already has some security. We all know

Too expensive, to hard to maintain, and experience has shown that it
does not solve a problem: We have all these feature availabale for years
but they are rarely used.

Thus I think it is better to split the problem:

 1. Find the right key matching a certain mail address.

 2. Make sure that you have the latest update of that key (for
    revocations) and detect a key change.

PKA is about the first while other methods (e.g. TOFU) is about the
second.  If you already have a key matching a mail address this is not
required.  Some fine tuning will be required to see what to do if you
already have two matching keys for the same address in you local
keyring.

> In 2006 you wrote that DNS will get more secure by the deployment of
> DNSSEC. We know this didn't happen. I'm very sceptical it will ever
> happen. Some IT sec people at Google and Yahooo have recently publicly
> commented they don't like DNSSEC. It has various problems, the biggest
> one being that it has been vapoware forever and nobody uses it. By

I don't buy that vaporware argument; that is too similar to the "IPv6
won't ever be used".  But: DNSSEC has no distributed security and we
have meanwhile learned that there are powerful organisations which will
likely subvert the security of DNSSEC as soon has it gets into real use.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.