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

From: Bill Manning <[email-masked]>
Date: Thu, 4 Jul 2002 21:08:14 -0700 (PDT)

it is wise to retain the distinction that using DNS to distribute 
 appkeys may not be the smartest thing, for the reasons mentioned.
 I think that the current snapshot is deadon to expire data.

 wrt OE, the keying material is being used to build IPSEC "tunnels"
 so having a key tied to the IP address being considered for use
 is a good thing. And the DNS looks like the "best" way to push
 them around.

% ...let's see, my main points are that the complexity is hidden in the 
% interaction of the security models and needs of DNS and applications 
% and that we really do want to avoid the "eggs in one basket" syndrome.
% 
% One last thing, I am curious to see how this pans out with 
% opportunistic keying.  But this message is long enough as it is...
% -- 
% -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
% 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/>
% 

-- 
--bill

--
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: David Conrad <[email-masked]>
Date: Mon, 08 Jul 2002 12:38:39 -0700

On 7/4/02 7:44 PM, "Edward Lewis" <[email-masked]> wrote:
> KEY RR's are going to be large - so if we stuff a
> couple of them at one domain name (one KEY RR set) we will either
> trip into TCP or need EDNS0 to enlarge the packets.  (Of course this
> is also true for CERT RR's - even more so.)

You already need EDNS0 to indicate support of DNSSEC.

> The complexity that I am concerned with is architectural and
> administrative.  

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

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?

> If  there is plan to use DNSSEC to protect the
> delivery of keys to application elements, the problem is that we are
> imposing on application the security model being used by DNS.

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

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

> Morale of the story - 1) trying to inflict security that benefits
> applications that need "freshly" secured data harms the DNS through
> more traffic.

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.

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

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

Rgds,
-drc