ietf
[Top] [All Lists]

Re: Proposal to use DNS as public key repository

2003-09-12 18:19:12
I propose we use DNS to keep the meeting minutes.

Seriously, two things: This should be on namedroppers, and I have some
issues with it.  Most obvious being that LDAP is already used in this
capacity. Secondly, there are multiple mail servers that handle a message.
Just look at the headers from an ietf list message. Having each mailserver
do these lookups and then sign the message many times is a lot of work,
and adds many times more text to the message in the form of signatures.
Further down on the list is the comment that mailserver authentication
isn't widely used. Only Residential ISPs have per user accounts.
Commercial ISPs don't have this data, but still provide relay services to
business users. And way down on my list is the point that many devices
just send mail, and don't have accounts.

                --Dean


On Fri, 12 Sep 2003, Sergey Babkin wrote:

Thanks to everyone for the pointers! One of the concerns I had
is that the idea looks really simple, why nobody has implemented
it already? - and it turns out that they already did. Though not
exactly in the same way. The SECSH document below is actually
for distribution of the fingerprints, not actual keys. Also
both of these documents have a very fixed and restricted
format for the keys. I think that providing an arbitrary
string implementation is easier and more flexible: i.e. you
would not need separate standards for ssh and ipv6 - they would be
covered by the same record type, with the only difference being the
key type field in the value.

Joel Jaeggli wrote:

The problem with public keys is not distribution... The distributions
machanisms we have now work fine.

Maybe I'm not up to date with the recent initiatives, but I so
far I don't know of any other way to distribute keys to the
whole world without registering them with some private repository.

it's getting people to generate
validate and use them.

Well, I have the second part of proposal for this. More exactly,
for the e-mail application.

What's the reason that the users don't use the crypto signatures?
Because it's difficult to do with the e-mail software they have
or because the whole concept of cryptography is too difficult
for them to understand. So it would be nice to move this
issue to the infrastructure level to make it transparent to the users.

Many ISPs (and IT departments) already require the users to enter
a password to send e-mail. So the mail server knows reasonably
well who the sender is. What it can do now is write this user
information into the e-mail's headers, then calculate the checksum
of the whole message and sign it with the mail server's key
(and possibly do the same thing for the identity-relation portion
of the header). When the addressee receives the e-mail, he can
look up the server's private key and check the signatures, to make
sure that the sender is who he claims he is.

Another easy use comes to the SMTP connection authentication:
ask the connecting server for identity, look up the private key
on DNS and authenticate through a crypto-challenge. Pretty
much the same thing as SMTP allows to do now except for the need to
exchange the keys in advance.

-SB

 On Thu, 11 Sep 2003 Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:

On Thu, 11 Sep 2003 22:27:25 EDT, Sergey Babkin 
<babkin(_at_)bellatlantic(_dot_)net>  said:
Hello,

I think that I've found an easy way to distribute the public keys:
put them into DNS. The records would look like:

Go to:

http://search.ietf.org/

query 'dns public keys'

Of particular interest:

For SSH public keys: 
http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-05.txt

IPSEC keying: 
http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-07.txt

See also RFCs 2536-2539,  and all the other DNSSEC RFCs.



--
--------------------------------------------------------------------------
Joel Jaeggli           Unix Consulting         
joelja(_at_)darkwing(_dot_)uoregon(_dot_)edu
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2