Subject: Re: [Design] Re: the KEY debate

From: [email-masked]
Date: Mon, 05 Aug 2002 10:16:20 +1000

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> >>>>> "Mark" == Mark Andrews <[email-masked]> writes:
>     Mark> 	We have basically already made a decision about whether we
>     Mark> 	should have different type or not for application keys.
>     Mark> 	DNSSEC is one application and the decision was made to
>     Mark> 	give it its own type by removing the other uses.
> 
>   "we", being whom? 
>   I do not agree that there is any consensus on this.
>   I will agree that there is some concern with KEY records at the APEX. 
> 
>   The problem was raised in Salt Lake City. 
> 
>   It would be nice to ask for a specific sub-type, but frankly, I don't care.
> Sorting through the types isn't that big of a deal. Given the sizes of the
> resource records and the desired presence of DNSSEC, the answers may well be
> large already.
> 
>   I was unable to attend the SIKED BOF. The reports that I heard indicate
> that a small number of people who hadn't actually read any of the drafts that
> specify KEY did a bunch of handwaving on how there was no trust model. 
> 
>   I see these as efforts to derail DNSSEC deployment. 
>   

	I'm saying that a *implicit* decision was made.  The working
	group made the decision by separating KEY for DNSSEC use
	only.  That set a precedent.

	If one application (DNSSEC) needs a seperate type to store
	keys then it can be argued that all applications that needs
	keys need seperate seperate types.

	There is no shortage of types.  If we exhaust IN then we can
	add another class.

	Mark

> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls 
>  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architec
> t[
> ] [email-masked] http://www.sandelman.ottawa.on.ca/ |device drive
> r[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy");
>  [
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Finger me for keys
> 
> iQCVAwUBPU1d2YqHRg3pndX9AQFR7AP+JyjTi+mWqYOrSOOqsNXcD86y1EaRvyTR
> Jxf9hwNd+BLTkR7vDqZT8lRhIb3eX1dNhvI8u6YlOYqwx8yd44GZChdsu5INcgzE
> T5TK+350q+mU829HRSfxntKvmGN4HnmS8nQEZA2IYeUt1ZobRgrZcAXzM2BCvTT5
> 6pGsu2flF/E=
> =J88s
> -----END PGP SIGNATURE-----
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Tue, 6 Aug 2002 14:39:34 -0400

>specify KEY did a bunch of handwaving on how there was no trust model.

?

The only documents relating to the KEY RR are RFC's 2065 and 2535 
(latter obsoletes the former), and neither was under discussion at 
the SIKED BoF.  The fact is that a large part of the discussion did 
focus on a lack of a trust model, this so-called hand waving was 
detailed enough to convince the me that we were attacking the problem 
from the wrong direction - namely from DNS out to the applications.

>   I see these as efforts to derail DNSSEC deployment.

I don't see DNSSEC (deployment) tied to the application key issue at 
all.  No one questioning the SIKED BoF ever raised a an issue with 
DNSSEC.  In fact, the same group (SAAG) that was putting SIKED's feet 
to the fire are the same that hosted the DNSSEC WG (I didn't misspell 
DNSIND, DNSEXT, or DNSOP) for much of the 90's, i.e., they started it.

While now I know that Michael wasn't able to attend the BoF, I was 
disappointed that there was no one at the BoF to address the OE work 
in any capacity.  I was really hoping to have someone talk about that 
to help bolster the pan-application desire for a common DNS solution. 
Since that didn't materialize, I've come to feel that it is up to the 
applications to decide what they want independently.  Sometime grand 
unification schemes are not the right approach.  (The lack of an OE 
presentation isn't the only reason I changed my mind, but it was a 
step towards the change.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Aug 2002 22:38:38 +0200

Edward Lewis <[email-masked]> writes:

> all.  

I think this depends on what you mean with DNSSEC.  If all DNSSEC is
to you is a secure DNS infrastructure, then clearly application keys
has nothing to do with it.  But DNSSEC was designed to support key
storage for applications (please read the RFC 2535 abstract), and if
you consider DNSSEC to be a bearer for application keys, then removing
that functionality from DNSSEC and excluding CERT RR from a DNSSEC
update, it clearly derails DNSSEC deployment.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 17:01:46 -0400

>storage for applications (please read the RFC 2535 abstract), and if

I know, I was one who gave many tutorials, workshops, etc. saying this.

I was wrong.  Mistakes were made.  People wasted time.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 07 Aug 2002 00:25:50 -0400

>update, it clearly derails DNSSEC deployment.

DNSSEC charter was to secure the DNS infrastructure.
In order to do that it was necessary to distribute keys for DNS,
it was a logical minor extension to allow other uses of the same
record.
Since RFC2065 KEY record has been restricted more and more each year
as sub-typing is a bad thing. There are three ways that I see that
DNS can help applications with keying
         store the keys in DNS
         store footprints of the keys in DNS (when protocol can pass the key
                 in-band).
         point to where the key is available from.

The first one can either be done by application specific type or some naming
schema, it is much easier to avoid problems with types than with names,
it is harder on DNS implementations (until they fully support unknown types).
The footprint solution requires new type.
The pointer solution needs careful considerations on how trust is
transferred from DNS to say LDAP.

One other thing that I took from the old KEY discussions was that every
application wanted to be able to carry some information along with the
key, the only way to do that in KEY RR was by using flags.
This is a real bad idea, I hope new <app>KEY RR types will consider
what information makes sense to carry with the key and encode that in
the RR type.

Speaking as a co-char, I encourage new types a this point in time.
If I'm wrong, again, so be it, no one can say that one approach is better
than the other one, and so we picked one, I hope to see in addition to
your PGP draft, one for SSH and another one for IPSEC.

         Olafur

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2002 21:47:51 -0400

-----BEGIN PGP SIGNED MESSAGE-----
[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:
    Edward> unification schemes are not the right approach.  (The lack of an OE 
    Edward> presentation isn't the only reason I changed my mind, but it was a 
    Edward> step towards the change.)
 
  The offer was made. I was not placed upon the agenda, as we had a very well
developped draft that you could read.

  The time for the BOF arrived while we were busy trying to debug some
"running code" that had died in an unexpected way, and then the time left,
and we hadn't moved.  

  That was our fault. But, we could very well not have even been in the
building or in the city. That shouldn't affect IETF progress.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [