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

From: Edward Lewis <[email-masked]>
Date: Mon, 8 Jul 2002 17:09:54 -0400

At 12:38 PM -0700 7/8/02, David Conrad wrote:
>I find the 'architectural complexity' argument somewhat amusing.
>
>The complexity of putting application keys into the DNS pales to
>insignificance in comparison to the complexity of actually implementing and
>deploying DNSSEC.  The code is already there (well, almost -- presumably
>would need to implement the APPKEY RR, but that is conceptually no different
>than any other RR).

My concern is we might be making the interaction between DNS and an 
application more complex.  This isn't related to how complex the code 
is.

>As for administrative complexity, I'm confused how this is particularly
>relevant to DNSEXT.  Was there much concern about the administrative
>complexity of actually using as opposed to defining (say) the LOC RR?

I wasn't involved in any of the LOC RR discussions, nor have I seen it used.

>Which, in some cases (e.g., opportunistic keying), is presumably OK as the
>thing you are trying to lookup is DNS based.

I dunno.  I'm trying to rationalize this, I made remarks on this in 
an intervening message.

>>  By tying DNS security to
>>  application security we are "putting our eggs in one basket."
>
>A valid concern.  However, in a few select applications (e.g., ssh), you are
>already relying on the DNS so it isn't clear to me how much additional
>vulnerability is raised should the DNS security model fail.

Not exactly true, regarding SSH.  SSH still would require that the 
key in DNS matches the key offered through the connection.  One would 
have to corrupt both the DNS and the host to carry out a "host in the 
middle" attack.

>You are assuming additional DNS traffic is harmful.  Why?  I hear there is a
>glut of bandwidth...  More seriously, DNSSEC _will_ result in more traffic.
>Any additional traffic caused by something like APPKEY would, I suspect, be
>lost in the noise.

There might be bandwidth available (my home is still a 28.8max POTS 
line), but there's also the latency issue.  Then again, my argument 
isn't about on-the-wire complexity/load, but the interactions that 
would lead to a spectacular meltdown (eggs) when there's a problem.

>
>>   2) tying TTL and SIG validity periods is a bad idea
>>  (but seem to keep popping up).
>
>You are saying we should ignore the SHOULD in RFC 2535 section 4.4?  The
>implication of this would, of course, be that you'd have unverifiable data.
>If your resolver would be able to handle such data, then I don't see the
>point in having DNSSEC.

After rereading 4.4 or 2535, yeah, I think that cache's shouldn't 
trim the TTL.  For example, if a piece of data is ttl'd for 4 days 
but the key signing it is valid for 2 days, who's to say that the key 
won't be resigned for another 4 days?  Why throw out the data when it 
will be valid again?

>>  (TTL - database coherency, sig validity - crypto health.  Don't
>>  confuse them.  Yes, the signer should truncate the ttl to the
>>  validity, but not the cache's.  I'd expound further, but this isn't
>>  why I'm writing.)
>
>While I am not confusing database coherency and database validity, it isn't
>clear to me that coherent but (potentially) invalid data is of any use to
>anyone actually interested in security.  Indeed, it would seem it would open
>up windows of vulnerability if presumably secure resolvers can accept
>unverifiable data.  Expound please.

The point is that if an application cares enough about the security 
of the data it is using, the application will have to do the check 
itself.  "Arrived securely" data will largely be safe enough for most 
run of the mill applications.

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?

DNS data is not real-time by its nature.  This is why I bristle at 
attempts to make the data (too) time sensitive.

I've expounded...happy? ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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 19:28:48 -0400

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

---

From: David Conrad <[email-masked]>
Date: Mon, 08 Jul 2002 22:44:54 -0700

On 7/8/02 2:09 PM, "Edward Lewis" <[email-masked]> wrote:
> application more complex.

Again, I'm confused how this is particularly relevant to DNSEXT.  If you
want application complexity related to the DNS, look at NAPTR and 2916bis.
APPKEY looks much simpler to me, but isn't this a question for the
application developers that want to make use of APPKEY?

> would lead to a spectacular meltdown (eggs) when there's a problem.

If you believe DNSSEC is going to happen, then you implicitly assume the
bandwidth and CPU consumption for DNS is going to take a huge jump.  If this
will lead to a "spectacular meltdown", then let's make 2535bis say "Don't do
DNSSEC" (I know many people who would pee themselves in joy at the
prospect).

However, I fail to see how adding another RR, even a big RR like an APPKEY
could be, is going to trigger a "spectacular meltdown".  What am I missing?

As for bandwidth consumption and latency, I would be somewhat stunned to
find that an X.509 CERT verification (including verification of CRL) is any
less consumptive of time or bandwidth from the end user's perspective (of
course, it will be less from the DNS server's perspective -- is that your
point?).

> won't be resigned for another 4 days?  Why throw out the data when it

Um.  How do you know it is valid and not spoofed?

> Should SSH then end the connection in 120 seconds?

If someone has made their key validity period be 120 seconds, then that
would appear to be the desired behavior, would it not?

> DNS data is not real-time by its nature.

Interesting theory.  That explains why a TTL of 0 isn't allowed and why DNS
based load balancers are such complete failures.  Err, wait...

Rgds,
-drc

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 9 Jul 2002 09:24:57 +0200

> won't be resigned for another 4 days?  Why throw out the data when it 

What 4.4 does is define a state in which a cache should be after a
signature expires. If data that is supposed to be secured is not in a
state that it can be trusted it should not be around, at least not for
anybody who queries that data.  If an implementation wants to hide the
data from the clients until the data can be verified again then that
is OK but I do not think it's really efficient. ( The amount of data
in a query for the SIG only -- where you will get all the SIGs for a
name -- is probably bigger than for a query of given TYPE where the
SIGs for that TYPE and the TYPe itself is returned. )

::01af 

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi