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

[Jeroen Massar]

On Wed, 2006-04-05 at 02:17 -0500, Brad Knowles wrote:
> At 10:28 PM -0400 2006-04-04, Danny Mayer wrote:
> 
> >  These three lead to one big question though:
> >    Can we start doing automatic key verification for mail !?
> 
> 	See DKIM.

Which is not there yet and will take the coming X years to be designed,
developed and deployed. While PGP is working already for several years
and has been proven to work very reliably.

> >  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.
> 
> 	Think about ten million users, or fifty million.  Each user 
> having several hundred bytes (or even several KB) of data stored for 
> them.  Stored in the DNS.  In a single flat zone.  Bad idea.  Like, 
> really bad idea.  Like, one of the worst DNS-related ideas I think 
> I've ever heard of, at least in a very long time.

Checking http://dailychanges.com/ status of domains on 4/4/2006:
49,340,982 .com
7,425,723  .net

etc. so what was the issue again of storing a couple of million records
in DNS? If you claim it is a 'bad idea' then why does the CERT record
exist at all when it has the intentions of allowing PGP keys to be
stored? ;)

Using for instance nsd (http://www.nlnetlabs.nl/nsd/) should not pose a
problem in serving these amounts of contents.

It is more a 'separation' question I am asking, so that one has a
subzone for these records, which will allow one to have say 3
nameservers, which are registered at the tld servers thus can't easily
be changed, for example.org but have 20, which you stuff in example.org,
handling the load for _certs.example.org where the CERTS are stored.
It's a choice item giving the possility of doing it.

> 	And it shares most of the same problems in this respect with 
> DKIM, if you try to push DKIM to process data at the individual level 
> as opposed to the domain level.
> 
> 	Very highly non-scalable.

See below and also in my original message...

> >  Of course this will also require a lot of software to make it working,
> >  but this is going in the right direction! :)
> 
> 	Possibly, but I'm not convinced.  There's lots of scalability 
> issues that need to be given some serious thought before you just 
> leap into the fray and start spraying about large DNS records for 
> each user, regardless of any other factors that are involved.

Which is why I noted that one could have a single pgp key for a complete
domain could cover all the cases where one doesn't have the enduser
signing the messages but a central system doing it for them. Which is in
effect what DKIM does but allowing the freedom to have per-user keys
too.

Eg large sites like hotmail/gmail/yahoo/whatever could have a 'websign
key' where the outbound webengine signs the message for the user.
Presto, 60M users served with one key. This situation is the case for a
large percentage of the ISP's around the globe, especially as they
should be 'forcing' their clients to send outbound mail over their SMTP
gateways (using submit :) instead of using the one which is acting like
an open relay.

And the good parts:
 - this can work today
 - MTA or MUA only have to do a PGP verification of the message
 - very easy to deploy and setup
 - no transition needed, just deploy at the ISP and it works.

of course many/all sites have to participate otherwise it doesn't have
much effect, though one could say "drop/bounce anything not signed" at a
certain point.

I don't care if we go for PKA or CERT records as long as the silly
spoofing of source addresses gets halted. Spam and virusses are easily
discarded using things like SpamAsssassin and ClamAV etc, but bounces
might be legit so one still gets those and lots of them from all the
virusses and spams spoofing your email address toward non-existent
addresses or folks with auto-replies etc.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20060405/bc814cbb/attachment.pgp