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

From: "Scott Rose" <[email-masked]>
Date: Wed, 10 Jul 2002 13:14:51 -0400

There was a reference to APPKEY (Jakob's draft?  not certain and I don't
have it in front of me).  It was taken out (by me probably) when we saw that
there was a lot of debate about how to store application keys in the DNS.
The APPKEY draft only proposed one possible solution and we didn't want to
say it was the choice option.

A reference to any application key draft could be included, just to say
other means exist and are being debated.

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.

Scott

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "Randy Bush" <[email-masked]>
Cc: "Simon Josefsson" <[email-masked]>; "namedroppers"
<[email-masked]>
Sent: Wednesday, July 10, 2002 12:18 PM
Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

> > this are items for the siked effort.  this document should not try
> > to encompass that effort.
>
> I believe that the argument was that the restrict-key-for-dnssec draft
> should not advance in the absence of an app-key draft advancing, because
> otherwise we lose functionality.   So if we make a normative reference to
> the app key draft in the restrict-key draft, that solves that problem.   :
> '}
>
>
> --
> 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: Dan Massey <[email-masked]>
Date: Wed, 10 Jul 2002 14:04:31 -0400

> say it was the choice option.

I think Scott took it out, but I also strongly agree with that decision.
This thread, past discusions, the last BOF, and so forth all show that
there is active discussion on application keys so I don't think restrict key
should point to a particular approach.

> other means exist and are being debated.

I don't think key restrict should go further than the current text that
says:

> Other documents can describe how DNS handles application keys.

This does not point to a specific approach and leaves a clear path
for some application key document to gain consensus.

The main point of key restrict is just that application keys don't
belong in the KEY record (not equivalent to "don't belong in the DNS").
Regardless of  what else happens, I haven't seen any reason why this
would change.  Since we have consensus on the don't belong in
the KEY record, let's make that change so things like the DNSSEC
revision, operational policies, and so forth can all benefit from this
simplification.

Dan

---

From: Edward Lewis <[email-masked]>
Date: Wed, 10 Jul 2002 14:33:34 -0400

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

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 10 Jul 2002 14:59:01 -0400 (EDT)

> the app key draft in the restrict-key draft, that solves that problem.   :

Let me give some background, RFC2065 observes that now that we have KEY
record for DNSSEC we can piggy-back on that to provide key distribution
for other uses. This is carried to RFC2535.

Some DNS people have been advocating that the biggest mistakes in DNS
are when multiple things share the same RR type, it is simpler from
a specification perspective but it has operational and development issues.

Now back to KEY,
Dan Massey started a DNSSEC test bed and it noticed that his organization
had all the public services located at the zone apex, web, ftp, mail, ssh,
etc. If each one of these was allowed to put key records in to the apex
KEY set it got big.

NLnetlabs people run a DNSSEC test bed and they noticed that KEY sets for
children where going stale as the child did not send the parent the key
set to sign. They proposed a change to DNSSEC that delegation KEY records
be stored at the parent (KEY@parent).

There is a workshop in Malmo on DNSSEC for operators and
international lawyers to discuss the implications of signing KEY sets.
The lawyers did not like that TLD's sign application keys.

I give a whole day seminar on DNSSEC in Iceland and the information flow
in there, after answering many times "there is no other way" to
questions like "Why do something this complicated", I concoct the
predecessor of the DS record.

The original DS spec contains text motivated by all the experiences above
on why application keys should not be allowed to coexist with this starts
a discussion how to store non-DNS keys. The consensus of this discussion
was that DNS keys should be separated from the non-DNS keys, but there is
no consensus on how/if to store the non-DNS keys. In order to force the
issue and motivate people to discuss full ideas the chairs on 2001/10/26
invited submissions on various ideas on how to store non-DNS keys in DNS.
Dan and Scott submitted a paper motivated by all above named
restrict-key. The goal of this paper is to prevent harm to DNS and motivate
people to find a different solution if one exists.

I personally prefer some variant of APPKEY is the solution, my
current preference is to give each use (protocol or application) its
own type code.

The siked effort ([email-masked]) is the appropriate forum for this
discussion as this is a larger issue than DNS.
If a application comes to DNSEXT with specifications  on a new type to
store keys and the security area people are comfortable with
that specification, DNSEXT will review the specification and comment on it.

Please keep the discussion on this topic focused on the issue at hand.
"Is restricting the use of the KEY RR a good idea".

	Olafur