Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released)

From: Jeroen Massar <[email-masked]>
Date: Tue, 04 Apr 2006 14:24:18 +0200

[Cross-post-reply to most-likely interrested parties... strip where
needed]

On Mon, 2006-04-03 at 14:13 +0200, Werner Koch wrote:
 
> We are pleased to announce the availability of a new stable GnuPG
> release: Version 1.4.3

Neat ;) Muchos thanks to all the developers for their work!

>     * Implemented Public Key Association (PKA) signature verification.
[..]
>     * New auto-key-locate option that takes an ordered list of methods
>       to locate a key if it is not available at encryption time (-r or
>       --recipient).  Possible methods include "cert" (use DNS CERT as
>       per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP
>       server for the domain in question), "keyserver" (use the
>       currently defined keyserver), as well as arbitrary keyserver
>       URIs that will be contacted for the key.
> 
>     * Able to retrieve keys using DNS CERT records as per RFC-2538bis
>       (currently in draft): http://www.josefsson.org/rfc2538bis

These three lead to one big question though:
  Can we start doing automatic key verification for mail !?

It would be really good if there would now come a draft which will
propose the standard order of getting a key, when one doesn't have it or
wants to get it again. This release of GnuPG allows one to already
specify it. It would be really good if this was standardized and also
implemented. Especially in combination with a domain policy (which could
be incorporated in say SPF).

Thus, eg I mail from [email-masked], one can lookup _policy.unfix.org,
which will say "mail:PGP:required" or something similar. SMTP
clients/servers receiving mail signed by me, can then use one, or more,
of the key retrieval techniques to fetch the key. PKA + Cert become very
good for this and thus allow automatic verification. When the mail is
not signed or falsely signed, one can discard the message based on the
policy.

For ease of deployment SMTP gateways, which receive mails from
authenticated (IP or user/pass etc based) can auto-sign unsigned email
with a generic 'automatic' key. Existing clients won't thus be affected,
unless they don't use the ISP's SMTP gateway. If they want to avoid
using the ISP's gateway, they need to have their key in DNS though.

This all though leads to a concern on the placing of the CERTS. Having a
large user base would mean that one has say 600k records or more in the
main zone for a domain, which gets reloaded every now and then when one
needs to update it. It would IMHO be better to be able to off load those
records to say _cert.example.org. Which has several benefits, one can
then run their normal DNS adminstration and delegate the CERT records to
a dedicated DNS server set which can handle the updates easier or simply
runs out of a DNSBackend. This will also be easier management wise with
DNSSEC I expect and remove the strain from the main boxes, which
currently might have maybe upto 100 RR's on average in a zone,
especially in the case of webhosting farms where one only specifies the
www.example.org and nothing else.

Of course this will also require a lot of software to make it working,
but this is going in the right direction! :)

Greets,
 Jeroen
  (Who sees this way as one of the better ways of
   killing of forged mail, bounces etc...)

---

From: Julian Mehnle <[email-masked]>
Date: Tue, 4 Apr 2006 13:37:35 +0000

Jeroen Massar wrote:
> [GnuPG 1.4.3 / Public Key Association (PKA) / CERT in DNS / RFC 4398]

Indeed the SPF project has plans to introduce another revision of the SPF 
protocol, now that SPFv1 (v=spf1) will be out as an IETF RFC within the 
next few weeks.  While v=spf1 only supports IP-address-based authenti- 
cation of the envelope sender, the idea has long been for SPF to be much 
more than that, i.e. to be a "Sender Policy Framework" allowing domain 
owners to specify a wide range of policies, covering non-envelope (RFC 
2822) identities and authentication methods like DKIM, PGP, and S/MIME.

The rough timeline could be for that revision to be released sometime in 
Q3/2006 to Q1/2007, depending on the feature set chosen (which is still 
open to debate).

> [...]
> records to say _cert.example.org. [...]

While for v=spf1 mostly TXT RRs are used in practice, SPF has been assigned 
a dedicated "SPF" RR type (code 99), which is already being used (queried) 
by a few implementations.  Also, SPF's macro feature would be useful for 
specifying custom DNS zone layouts for where to search for key records.  
(Are there ones besides CERT/RFC2538/RFC4398?)

What do folks -- especially the gnupg-devel ones -- think about using SPF 
for that purpose?  Are there any non-obvious fundamental issues that need 
to be taken into account?

Julian.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Julian Mehnle <[email-masked]>
Date: Wed, 5 Apr 2006 13:26:37 +0000

Werner Koch wrote:
> On Tue, 4 Apr 2006 13:37:35 +0000, Julian Mehnle said:
> > What do folks -- especially the gnupg-devel ones -- think about using
> > SPF for that purpose?  Are there any non-obvious fundamental issues
> > that need to be taken into account?
>
> I consider SPF far to complex to solve the simple goal of
> authenticating the source of an email.  It does not stop spam, as 
> this requires content filters and the jurisdiction and won't
> authenmticate the full message.

Let me say this in advance: I do NOT want to start a lengthy discussion 
across several mailing lists about that.  But I think there are a few 
misconceptions to be clarified:

SPF does not aim to stop spam, it aims to stop forgery -- not necessarily 
by directly doing the authentication itself (SPFv1 cares about the 
envelope sender only, the next revision aims to do more than that).  In 
particular, SPF does NOT aim to replace DKIM or PGP, but to complement 
them by giving domain owners the means to publicly specify their mail 
sending policies in a standardized way.

(BTW, if you think SPF is "too complex", then you should take into account 
that the SPFv1 spec is over 40 pages long only because it already includes 
lots of lessons learned, security considerations, and other non-authorita- 
tive stuff.)

> The goal of PKA is much simpler: Authenticate the From: header and
> allow the MUA or MTA to detected spoofed messages this way.
> 
> The ability to do an opportunistic encryption using the PKA framework
> is just a very welcome side-effect.

It is exactly that side-effect of opportunistic encryption that SPF aims to 
support.

Is that support (i.e. the standardized means to publicly specify your 
sending/signing policy) not something worth to be considered?  If you 
think that PKA already does the part _you_ want, then you may be missing 
the fact that not every sender may choose PGP+PKA as their authentication 
method, and that receivers may not want to check _all_ the methods out 
there for a given message until they find one that actually authenticates 
the message.  SPF could act as an arbitrator for the various existing 
authentication methods.

---

From: Julian Mehnle <[email-masked]>
Date: Wed, 5 Apr 2006 13:38:31 +0000

Julian Mehnle wrote:
> It is exactly that side-effect of opportunistic encryption that SPF aims
> to support.

Oops, please read that as "opportunistic authentication".  But that's not 
all that different.