Subject: RE: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

From: "Jason Coombs" <[email-masked]>
Date: Mon, 8 Jul 2002 15:15:15 -1000

Aloha, Derek and Edward;

(I've enjoyed this discussion, thanks to both of you)

> Where keys-in-DNS helps is the first connection.  If you've
> never contacted a host before, you have no way to know whether to
> trust the key.  If, however, you can compare the key in DNS to the
> key the server hands you, you get one more level of protection.

This has already been mentioned, but aren't certificates a better
way to accomplish the application security you describe for that
first connection?

The attacker has another hoop to jump through in order to be an
attacker: they have to steal the secret key that corresponds to
the root certificate in the trust chain, or discover it through
successful cryptanalysis. This seems comparable to the additional
hoop required to spoof DNSSEC responses delivered to resolvers
in your proposed scenario.

The difficulty of mounting the attack is identical once the
server gets keyed and certified. So how does a key in DNS
increase the difficulty of an attack, exactly? By requiring
the attacker to hijack or spoof two boxes instead of just
one? Trivial if the attacker is already a full-fledged MITM.

If DNSSEC is deployed for the Internet as a PGP-style web of
trust rather than a DNS-style hierarchical distributed database
or an SSL-style centralized certificate authority trust model,
you still won't be able to trust anyone whose key is signed by
somebody you don't trust, and if you trust everyone who signs
keys then you essentially trust nobody all over again but you
just spent a whole bunch of time getting there.

I know this is old debate, at least in cryptographic circles.
My point is simply to caution against assuming more security
than you really have and suggest that it may in fact be
inappropriate (or at best useless) to view keys from DNSSEC
as anything other than applicable to DNSSEC as suggested by
draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. Some sort
of APPKEY may be valuable, but if it isn't for the purpose of
defining an Internet standard key service for some sort of
Internet standard cryptographic system like some type of
international smart card ID system and associated single sign
on service (*cringe*) then APPKEY seems to me to be of value
primarily for private, custom applications that don't need nor
do they benefit from the standards process.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Derek Atkins
Sent: Monday, July 08, 2002 1:29 PM
To: Edward Lewis
Cc: David Conrad; namedroppers
Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

Edward Lewis <[email-masked]> writes:

> Try this for example:  SSH (a security sensitive app) validates the IP
> address of a host.  The net TTL of the validity is 120 seconds. Should
> SSH then end the connection in 120 seconds?  Should all applications
> cease making use of data from DNS once the resolver's copy of the .org
> key ttl's out?

Actually, this isn't completely accurate.  The security that SSH
provides is linkability between connections.  Assuming your personal
SSH Cache is secure (which may be false), you know that the host you
know as host.foo.com is the same host you knew as host.foo.com last
week.  Where keys-in-DNS helps is the first connection.  If you've
never contacted a host before, you have no way to know whether to
trust the key.  If, however, you can compare the key in DNS to the key
the server hands you, you get one more level of protection.

As for the timeout question, that is actually still under debate.
There actually _ARE_ applications that timeout their security after
some period of time.  IPsec does this (you have to periodically re-key
the connection).  A number of GSSAPI mechanisms stop working at the
timeout, too.  So, yes, in the name of security it MAY BE reasonable
to timeout the connection based on the TTL.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

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

--
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: "Derek Atkins" <[email-masked]>
Date: 08 Jul 2002 21:24:08 -0400

> way to accomplish the application security you describe for that

I wouldn't call it "better", but "different".  To be pedantic, DNSSEC
_does_ provide a certificate, by definition.  It's providing a binding
of a key to a name.  The only difference is that it's using the DNSSEC
key hierarchy instead of a non-DNSSEC key hierarchy for the
chain-of-trust.  But technically you do get "certificates" from
DNSSEC.

> in your proposed scenario.

The attacks against X.509 Certs are the same as they are against
DNSSEC, and vice versa.  Any attack you can mount against DNSSEC can
be mounted against a CA.  The real difference is that theoretically
you should be less successful with a real CA.  I say theoretically
because, well, "Verisign's Microsoft Certificate".

> one? Trivial if the attacker is already a full-fledged MITM.

Let's look at the SSH protocol..  The first time a clien connects to a
server, the server sends its key and the user is asked whether to
accept it.  If, however, the client makes a DNSSEC query for
<serverhost> IN APPKEY ..   and receives:

        <serverhost> IN APPKEY ...
                     IN SIG (APPKEY) ...

So, if the client compares the key from DNS against the key obtained
from the server, they have a higher level of assurance in that key (if
they match) than just accepting it blindly.

The user has a level of assurance that the key data in DNS is the data
that the owner of the domain put into the zone file.  A MITM could not
insert or change this data in the DNS, because they wouldn't know the
DNS signing key.

Now, you could call into question the ability of the DNS operator to
manage the keys, but the same can be said for CAs.  Similarly, if you
say the MITM has access to the DNSSEC signing keys, that's the same as
saying they have access to the CA Signing Keys.  A rose by any other
name....

> draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. Some sort

I believe you are mis-reading the restrict-key draft.  The draft is
just saying that the KEY RR should be restricted, not that the concept
of using DNSSec for KEY Distribution is flawed.  When I say 'key', I
mean the concept of a key (be it stored in a CERT, APPKEY, or FROZBAR
RR), not the "DNS KEY-RR".

-derek

---

From: David Terrell <[email-masked]>
Date: Mon, 8 Jul 2002 18:43:42 -0700

On Mon, Jul 08, 2002 at 03:15:15PM -1000, Jason Coombs wrote:
> draft-ietf-dnsext-restrict-key-for-dnssec-03.txt.

the dropping of all non-DNSSEC KEY records is non-controversial
because nobody wants to have to parse multiple KEY RRs _while_doing_
_DNSSEC_validation_, not because the idea that DNSSEC should not
be used for application keys has gained WG consensus.

-- 
David Terrell   | "If I had a nickel for every time I've seen a Usenet poster
Nebcorp PM      | slip in an ostensibly casual reference to how much smarter
[email-masked]    | he/she is than everyone else... why, I'd be able to throw a
wwn.nebcorp.com |party for all my Mensa buddies!" -- Miguel Cruz