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

From: [email-masked]
Date: Tue, 02 Jul 2002 06:30:06 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Limiting the Scope of the KEY Resource Record
	Author(s)	: D. Massey, S. Rose
	Filename	: draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
	Pages		: 15
	Date		: 01-Jul-02
	
This document limits the Domain Name System KEY resource record to
only keys used by the Domain Name System Security Extensions
(DNSSEC).  The original KEY resource record used sub-typing to store
both DNSSEC keys and arbitrary application keys.  Storing both DNSSEC
and application keys in one record was a mistake.  This document
removes application keys from the KEY record by redefining the
Protocol Octet field in the KEY Resource Record Data.  As a result of
removing application keys, all but one of the flags in the KEY record
become unnecessary and are removed.  Three existing application key
sub-types are changed to reserved, but the format of the KEY record
is not changed.  This document updates RFC 2535.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-restrict-key-for-dnssec-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Jul 2002 22:44:51 -0400

At 11:45 AM -0500 7/3/02, Ted Lemon wrote:
>Maybe this is a stupid question, but in what way does putting application key
>records into the DNS make it more complicated?   Does it *need* to be more
>complicated, or is this a bug in the specification that could be fixed?

First I'll present the obvious but rather weak argument - just to get 
it out of the way.  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.)

Okay, let's get serious now...

The complexity that I am concerned with is architectural and 
administrative.  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.  The 
security model for DNS should be tailored to the needs of DNS.  (If 
we plan to allow DNS to address the security of applications, then 
we'd need to make sure that the security model of DNS accounts for 
that.)  The administrative complexity is the extra burden placed on 
administrators to enter the keys into the DNS.  Okay, CERT RR's are 
just as hard to enter, but a KEY RR does not allow for the final 
check that a CERT RR does (CRL's, more flexible validation process).

Looking at the architectural complexity, keep in mind that DNS is not 
a layer under an application.  DNS itself is an application.  As such 
DNS has a security model (albeit one barely spoken or written), one 
that needs to address the use of caches and, well, not too much more. 
DNSSEC is designed to make sure that what ever the rightful 
(authoritative) administrator enters into the primary master server 
is what is seen by resolvers.  (Secondaries are covered too by TSIG, 
which I consider to be part of DNSSEC.  Differences of opinion on 
this are just terminology, which isn't all that important in this 
message.)

Applications are going to have other security needs.  SSH needs to 
make sure that the client has an account and can "beat the challenge" 
along with tunneling and encrypting traffic.  Email needs to make 
sure stored messages can be decrypted at a later point.  What I mean 
is that applications have different needs - amongst themselves and in 
contrast to DNS.

If we were to integrate the security models of applications to DNS 
then we'd have to deal with a 1:many relationship.  But there's 
another danger, one that has me more concerned and is why I stopped 
pursuing SIKED work soon after the BoF.  By tying DNS security to 
application security we are "putting our eggs in one basket."  If 
DNSSEC is broken, applications relying on KEY RRS only protected by 
DNSSEC also melt down.

I.e., the complexity of integrating security models can have a 
catastrophic impact.

Now, about the administrative complexity.  If an administrator is 
handed a KEY RR (okay, perhaps I should say APPKEY RR), there's a 
decision point.  Does the administrator check the validity of the 
key?  If so, this is a new requirement on DNS administration.  If 
not, then the applications are still at risk.

What if a CERT RR is required?  Then the application is "forced" to 
think about an authentication/validation process external to DNS. 
Yeah, self-signed CERTS can be put in the DNS and we basically have 
KEY's again, but then that's the fault of a lazy application design.

Now, to take a trip on a red herring/side bar, a situation came up 
during a DS RR workshop held yesterday (one reason my response is 
delayed).  We discovered that the snapshot code being tested 
truncated the TTL of the validated record set to the shortest TTL of 
any set used (KEY, DS) to validate it.  This means that when any part 
of the data used to validate the answer expires, the date also 
expires.

Good or bad?  Good in that it means that the cache will only have 
data that is currently valid.  But is that the goal of DNSSEC?  Not 
in my opinion, DNSSEC only makes sure that the answer arrives "good." 
DNS has never been concerned with real-time correctness, and I don't 
think we should start now.  Why?  Well, if TTL truncation remains, 
then once the root key TTL's to 0 in the server (or pick your 
favorite TLD), all data in the cache immediately dies - requiring 
more DNS queries to fly through the network.  Nowadays, if the NS for 
.org expires in "my" cache, at least ietf.org will last until it's 
ttl hits 0.

Morale of the story - 1) trying to inflict security that benefits 
applications that need "freshly" secured data harms the DNS through 
more traffic.  2) tying TTL and SIG validity periods is a bad idea 
(but seem to keep popping up).

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

The point of the sidebar is that trying to make DNS more acceptable 
to applications in the security sense can have a negative impact on 
DNS itself.  (And, if the application needs freshly checked data - 
let the application do it.)

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

---

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

At 9:08 PM -0700 7/4/02, Bill Manning wrote:
>  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.

Herein lies a personal dilemma.

On the one hand, my personal architectural view of DNS is that it is 
not suited for distributing keys, based on reasons I've mentioned 
before.

On the other hand, from what I know about the opportunistic 
encryption effort, the most efficient manner to distribute keys is 
via the reverse map of the DNS.  Additionally, the trust models seem 
to go hand in hand.

This tells me that 1) my personal architecture view of DNS is flawed 
or 2) my understanding of the opportunistic encryption effort is 
incomplete.  It is rare in nature to find "one clean exception." 
Usually making exceptions leads to longer term problems, sometimes 
exceptions are gateways to better models.

---

From: Peter Koch <[email-masked]>
Date: Tue, 09 Jul 2002 18:06:14 +0200

> No, seriously, if fugue.com doesn't have an A record (and thus, a related 
> appkey) then it has a CNAME that points you to the True Name of the host, 

With current reality (delegations only in COM) it must not. So, "fugue.com"
has an A RR and you have delegated "sshd.fugue.com" for fugue's "special
strings harmony department". Now your key's name would fall into their
namespace.
Did you say "2782"? OK, make it _sshd.fugue.com. But then we have this "_"
debate again.

-Peter

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 10 Jul 2002 12:50:23 +0200

Jim Reid <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> Given a name of a host, to find the SSH key you prepend
>     Simon> "ssh.".  In your examples, the answer to your question
>     Simon> would be "ssh.fugue.com IN APPKEY", "WWW.fugue.com IN
>     Simon> APPKEY" and "FTP.fugue.com IN APPKEY", respectively.
>     Simon> What's the problem?
>
> Well what if I had a host called ssh.fugue.com? 

Yes, how does that create a problem?

> Or what if prepending the protocol name makes the overall domain
> name too long? 

If this scheme is used (which I think is a bad idea), then you must
change the domain name in order to use application keys in DNS.  If
you are not willing to do that, noone is forcing you.

> I think that prepending the protocol name isn't so bad though it is
> a bit ugly. But the label for the protocol name should probably
> include an underscore so it doesn't clash with a hostname, just like
> underscores in SRV records.

I agree.  Using the owner name for this is not a good idea, but my
point is that it would "work".

I think I prefer NAPTR, it gives all the advantages of being able to
delegate application key zones to trusted third parties without the
disadvantages of overloading the owner name field and possible name
clashes.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 10 Jul 2002 13:57:38 +0200

Jim Reid <[email-masked]> writes:

>     Simon> Yes, how does that create a problem?
>
> Apologies,I was not clear. Suppose I delegate ssh.fugue.com and
> there's an A record for fugue.com which has an ssh key. In your
> scheme, that ssh key would have to go in the child zone which may be
> under a different administrative control.

I see.  Yes, that is a problem.  That's why I'm not proposing that
scheme; NAPTR seems more flexible.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 10 Jul 2002 15:04:29 -0400 (EDT)

On Wed, 10 Jul 2002, Edward Lewis wrote:

> At 1:14 PM -0400 7/10/02, Scott Rose wrote:
> >As for the overlap between Restrict-KEY and the DS RR draft:  I think I
> >understand the comment.  A referrence to how Restrict-KEY will update the
> >last part of the DS RR intro.  correct me if I'm wrong.
>
> I caught this too - I sent mail to authors and the IESG (because its
> in last call) yesterday after talking to Olafur.  That's exactly the
> location where I was the overlap.
>

I think DS should drop the first paragraph on page 3:
"Another complication of the DNSSEC" and replace that with a short summary
and a reference to Restrict-Key section 2 that does a better job of
documenting the issue.

	Olafur

---

From: David Conrad <[email-masked]>
Date: Wed, 10 Jul 2002 21:41:44 -0700

On 7/10/02 11:59 AM, "Olafur Gudmundsson" <[email-masked]> wrote:
> "Is restricting the use of the KEY RR a good idea".

Yes.  Has anyone been arguing that it isn't?

Tnx,
-drc

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 11 Jul 2002 23:01:01 -0400 (EDT)

> Yes.  Has anyone been arguing that it isn't?

That opinion has been expressed to me in private e-mails and
in person at the last IETF.

There is a feeling of betrayal by some people that looked to
DNSSEC as a ready made PKI that was just around the corner
has been taken away.

	Olafur

---

From: "Loomis, Rip" <[email-masked]>
Date: Fri, 12 Jul 2002 10:16:02 -0400

> DNSSEC as a ready made PKI that was just around the corner

But this isn't the "Internet Try-not-to-make-anyone-feel-betrayed
Task Force".  If we could find the ITTF, maybe those folks would
try to help us.

In the meantime, we're engineering.  Having KEY records available
for uses other than DNSSEC keys *might* have been at least an Okay
Thing.  Therefore, that was the way things were originally written.
However, experience shows that trying to deal with a load of extra
KEY records in the middle of each DNSSEC validation turns out to be
a Bad Thing.  We must therefore revert to being part of the I _E_ TF,
and update the RFCs appropriately.

The no-brainer way (IMHO) to engineer a solution that allows DNSSEC to
function is to restrict KEY for DNSSEC.  In fact, I haven't seen
any discussion of any other reasonable solution--and I am still going
on the basis that DNSSEC remains on the standards track and therefore
should be supported appropriately.

There was previous discussion of APPKEY and/or CERT records,
and I'm not quite sure how we (now) seem to have lost the previous
consensus.  For right now, though, I would ask that anyone who
can't live with the restrict-KEY draft *please* clearly state
your objections--once that's out of the way *then* we can address
APPKEY/CERT/SINK/whatever and engineer an appropriate solution.

Or am I missing something?

  --Rip