Subject: Proposal to use DNS as public key repository

From: Sergey Babkin <[email-masked]>
Date: Thu, 11 Sep 2003 22:27:25 -0400

Hello,

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

<entity-name> IN PKEY <key-type>:<key-value>

for example:

babkin.-at-.bellatlantic.net IN PKEY "ssh1:1024 37 1550134074134018781239180842531603373454309268407729175684597284860789522776765036113307635696866211228019143858148231273490
040923224920369195137540343909305234827187088861055260339103636904616201228905551802270012860844892213877621509748539922264245295221
03235374785283586385586920281234566901122551897435633"

(I'm not quite sure yet if the values can be in quotes and if
the spaces and other funny characters are allowed - but such things
are solvable by some sort of escape sequences).

To allow changing the keys without disruption, allow multiple
PKEY records for an entity, and accept a match to any of them.

Of course it would be only as secure as difficult it is to spoof DNS,
so you probably won't want to use it for login information. But
it's still adequate for less demanding application, such as
signing e-mail or establishing the identity of the SMTP servers.

-SB

---

From: [email-masked]
Date: Thu, 11 Sep 2003 23:03:47 -0400

> 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.

---

From: "Fritz F. Saad" <[email-masked]>
Date: Thu, 11 Sep 2003 21:10:23 -0600

Hi Sergey,

That's exactly what thinking and that's a cool way to distribute PKeys.
About spoofing, I agree that vulnerable but it take a bit of work .

Cheers,
Fritz.
----- Original Message ----- 
From: "Sergey Babkin" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 11, 2003 8:27 PM
Subject: Proposal to use DNS as public key repository

> babkin.-at-.bellatlantic.net IN PKEY "ssh1:1024 37
1550134074134018781239180842531603373454309268407729175684597284860789522776
765036113307635696866211228019143858148231273490
0409232249203691951375403439093052348271870888610552603391036369046162012289
05551802270012860844892213877621509748539922264245295221

---

From: "MDX Technologies Inc." <[email-masked]>
Date: Thu, 11 Sep 2003 23:18:07 -0400

-----Original Message-----
From: Sergey Babkin [mailto:[email-masked]]
Sent: September 11, 2003 10:27 PM
To: [email-masked]
Subject: Proposal to use DNS as public key repository

Hello,

for example:

-SB

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Sep 2003 20:20:41 -0700 (PDT)

The problem with public keys is not distribution... The distributions 
machanisms we have now work fine. it's getting people to generate 
validate and use them.

joelja

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       [email-masked]    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

---

From: Bill Manning <[email-masked]>
Date: Thu, 11 Sep 2003 22:28:06 -0700 (PDT)

% On Thu, 11 Sep 2003 22:27:25 EDT, Sergey Babkin <[email-masked]>  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'
% 

	You've missed the OE work and the ENUM stuff... all use
	public keys in the DNS.  And then there is our goofy
	persistent testbed for this stuff...  

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Sep 2003 09:09:29 -0400

>put them into DNS. The records would look like:

Generically, see:
      http://www1.ietf.org/mail-archive/ietf-announce/Current/msg17495.html

(There's a mail list hanging around, but I can't recall where the 
archive is and  I can't find it now.)

SSH others have mentioned that there is an effort to do this.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: Sergey Babkin <[email-masked]>
Date: Fri, 12 Sep 2003 20:12:13 -0400

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:
> 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

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Sep 2003 21:07:49 -0400 (EDT)

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

---

From: [email-masked]
Date: Fri, 12 Sep 2003 21:43:02 -0400

> sure that the sender is who he claims he is.

There's a good reason not to do this - what you're really signing may not be
what you thought.  If the server is signing the mail with its own key, what
you've established is the statement "The mail server said [email-masked] sent it".
Notice we haven't actually proven that fred did anything - we've proven the
(effectively) hearsay assertion by the mail server".

Now let's think about this - what if the server is *lying* to us?  There's
several threat models here:

1) If the server is compromised, you basically just lost *all* confidence in
all the signatures.  The reason that things like smart cards are attractive is
that compromise of one only loses one user's key, not the entire
organization's.

2) I set up a rogue mailserver at mail.foo.com.  I send a forged mail with a
bogus From:, and sign "yes, this mail is From: [email-masked]".  You then
look up my mailserver's key and check, and trust the claim.  What's wrong here?
Basically, you've equated "A mail server just said what it sent was the truth"
with "it actually is the truth".

You could probably create a variant where you only trust the mail server's
assertion if its key was itself signed by a third party with an endorsement of
the form "This mail server is in fact allowed to assert the source of mail for
the foo.com domain only", and then only trust it if it's foo.com mail, and not
nowhere.com mail.

I'd hate to deal with any mail to/from an e-mail outsourcer like psmtp.com
however. Their certs will be *huge* - I think they provide service for well
over 100K domains. So I'd have to either fetch a multi-megabyte cert to verify
a 2K mail, or I need a caching system for certs.  There's little to no joy in
that, especially since we're trying to fix a broken model in the first place...

A much better model would be finding a way to easily/painlessly push the
cert management back to the MUA where it belongs.

---

From: Sergey Babkin <[email-masked]>
Date: Sun, 14 Sep 2003 20:25:51 -0400

> issues with it.  Most obvious being that LDAP is already used in this

As far as I understand, LDAP has a different scope: it's intented
to be used within an organization while DNS has a world-wide
distribution.

> and adds many times more text to the message in the form of signatures.

In the simplest way it's enough to sign only at the first server
that receives the message from the user and check the signature
only on the last server that drops the message into an user's
mailbox.

> isn't widely used. 

Well, the e-mail authentication is only one use of the keys in DNS.
Actually, even the use of them for remote login is such not a bad idea:
when establishing a login instead of requesting a public key
from the user by some other means, the admininistrator can just
pull it from DNS and store locally to prevent the possibility of
spoofing in the future.

> Only Residential ISPs have per user accounts.
> business users. 

In this case it would be up to the business users to sign the
outgoing messages if they want so.

> And way down on my list is the point that many devices

This mail probably normally has some local destinations - a device
may be sending mail to its administrator (possibly on another side
of the world) but not to random people on Internet.

-SB

---

From: Sergey Babkin <[email-masked]>
Date: Sun, 14 Sep 2003 20:44:33 -0400

> you've established is the statement "The mail server said [email-masked] sent it".

Exactly.

> (effectively) hearsay assertion by the mail server".

Yes. But it's good enough for most practical situations (those
not involving courts and high security clearances).
 
> Now let's think about this - what if the server is *lying* to us?  There's

Just take this signature as an advisory, not a proof. This mode
is good enough for most situations.

> all the signatures.  The reason that things like smart cards are attractive is

Same thing as if a multi-user host with the users' keys on it
is compromized.

> with "it actually is the truth".

You can still trace the origin of the message to the creator of
the record mail.foo.com.
 
> assertion if its key was itself signed by a third party with an endorsement of

No, I think that this approach is useless, because it pretty much
returns the situation to how it is now. Registering the keys
would become difficult, plus there is always the question of
how the third party knows that it's signing what it thinks it's
signing.

> the foo.com domain only", and then only trust it if it's foo.com mail, and not

You can do it without all this infrastructure - just compare the
domain name of the key and the domain from which the e-mail has
allegedly originated. If they don't match, refuse to accept the e-mail.
 
> that, especially since we're trying to fix a broken model in the first place...

I think that storing the keys in DNS eliminates the need in such
certificates. Well, if you want something really secure, you would
still need the certificates, but for many practical purposes
the spoof-resistance of DNS is good enough.
 
> cert management back to the MUA where it belongs.

Well, if we look at rsh/ssh, I find that dealing with distribution
of the keys for ssh (especially that I have multiple keys
for different purposes - some for work, some for personal
use etc.) requires more effort than remembering passwords.
Tha same thing would be true for MUAs as well, and even worse. 

-SB

---

From: Dean Anderson <[email-masked]>
Date: Sun, 14 Sep 2003 21:43:17 -0400 (EDT)

> to be used within an organization while DNS has a world-wide

LDAP, like X.500, is designed with a globably unique namespace.  I
understand there are patches to do referals to other servers based on DNS
lookups of the CN. I've never run them, so I can't say to much about the
details. But I guess it works.

> only on the last server that drops the message into an user's

OK.

> pull it from DNS and store locally to prevent the possibility of

It could have been spoofed in the first place. And login assumes I always
have a static IP. If I have a dynamic IP, am I supposed to do a dynamic
update of my key?

		--Dean