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: "Simon Josefsson" <[email-masked]>
Date: Tue, 2 Jul 2002 13:36:29 +0200 (CEST)

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

> 	Title		: Limiting the Scope of the KEY Resource Record

IMO it is a mistake to prohibit core DNSSEC functionality without offering
an alternative for those that want to continue use the deprecated
functionality.

Suggestion: Ship restrict-key-for-dnssec together with the APPKEY spec,
assuming the scope of APPKEY is made the same as KEY-for-application was.

Also, quoting the security considerations:

   This document eliminates potential security problems that could arise
   due to the coupling of DNS zone keys and application keys.  Prior to
   the change described in this document, a correctly authenticated KEY
   set could include both application keys and DNSSEC keys.  If one of
   the application keys is compromised, it could be used as a false zone
   key to create false DNS signatures (SIG records).  Resolvers that do
   not carefully check the KEY sub-type could believe these false
   signatures and incorrectly authenticate DNS data.  With this change,
   application keys cannot appear in an authenticated KEY set and this
   vulnerability is eliminated.

This is a bogus consideration.  A resolver that doesn't use the correct
key for each purpose is broken, and removing one way of getting those
incorrect keys doesn't improve the situation.  This specification does not
fix security problem.  Continuing quoting:

   The format and correct usage of DNSSEC keys is not changed by this
   document and no new security considerations are introduced.

The last statement is plain wrong, prohibiting application key
distribution using KEY records of course has security implications  The
considerations are even major, since any existing security applications
using KEY RRs are made non-compliant.  This should be made clear.  Ideally
a transition plan should be discussed as well.

Suggested new security consideration:

   This specification prohibits storing of application keys in KEY records,
   which has immediate security implications for any applications currently
   using KEY records for this purpose.  However, it is not expected that
   many such applications exists.  Existing application are suggested to
   transition to [APPKEY].

   The format and correct usage of DNSSEC keys is not changed by this
   document, and the security considerations of [RFC2535] still apply.

--
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: Greg Hudson <[email-masked]>
Date: 02 Jul 2002 13:42:26 -0400

Speaking as someone who thinks it would be cool to protect keys using
DNSSEC:

> an alternative for those that want to continue use the deprecated

I don't think application keys in DNS is "core DNSSEC functionality." 
The core DNSSEC functionality is protecting existing DNS data (most
importantly, name-to-address and address-to-name mappings).

We don't have consensus on whether or not it's a good idea to put keys
in DNS or to protect them with DNSSEC.  As such, it is hard to progress
proposals which fix the problems associated with doing it the RFC 2535
way.

We do seem to have consensus that KEY is a bad way to put keys in DNS. 
It seems reasonable to say, "Don't do it this way; we will continue to
argue about whether we should be helping you to do it at all."

> assuming the scope of APPKEY is made the same as KEY-for-application was.

I have doubts that APPKEY is practical, by itself.  It seems that if you
have many applications with keys at the same domain name, you will
quickly exceed the EDNS0 UDP packet size limit and eventually exceed the
hard 64K limit.

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Jul 2002 11:20:42 -0700

> I don't think application keys in DNS is "core DNSSEC
> functionality."  The core DNSSEC functionality is protecting
> existing DNS data (most importantly, name-to-address and
> address-to-name mappings).

ack

> We don't have consensus on whether or not it's a good idea to put
> keys in DNS or to protect them with DNSSEC.

quibble: if we get consensus to put them in, i presume that they
would be authenticated with normal dnssec mechanisms.  i.e. the
latter should not be an issue.

> We do seem to have consensus that KEY is a bad way to put keys in

indeed, i believe this draft did pass wg last call.  this version
was a touchup to answer nits raised by the area director before
passing to the iesg.

> It seems reasonable to say, "Don't do it this way; we will
> continue to argue about whether we should be helping you to do it
> at all."

it is my impression that this is what is occurring.

randy

---

From: Rob Austein <[email-masked]>
Date: Tue, 02 Jul 2002 14:33:08 -0400

> importantly, name-to-address and address-to-name mappings).

Bingo.

> quickly exceed the EDNS0 UDP packet size limit and eventually exceed the

This is the so-called "subtyping problem".  In brief: conceptually, an
RRset is named by TYPE + NAME + CLASS, where "+" denotes (conceptual)
concatenation.  When such an RRset gets too big and all the RRs in
such an RRset are (conceptually) related, there's not much one can do
about it (this is part of the reason why MG RRs never caught on), but
when the RRs that make up such an RRset make up two or more
conceptually distinct groups that can only be identified by fetching
and examing the whole RRset (and, most likely, discarding the
irrelevant portions), it's the subtyping problem.

All the known ways of getting out of the subtyping problem involve
breaking the big RRset up into seperate RRsets by changing the
conceptual name (somehow).  The two common ways are either to use
separate TYPE codes or to use magic labels at the least significant
end of the NAME.  Which solution one prefers depends on how easy one
believes it is to add new TYPE codes to the DNS (opinions vary) and
how much one wishes to avoid using magic labels (opinions vary).

My understanding is that most (all?) of the folks proposing to use a
single APPKEY TYPE also propose to use the magic label approach.

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 2 Jul 2002 14:55:47 -0400

The main reason no alternative was bundled with the restrict-key draft was
because we didn't have any consensus about how to store keys in the DNS, but
a general consensus that the KEY RR was a bad choice.  In fact an entire BOF
was spawned to address a general version of this problem (SIKED).  Besides
APPKEY, there are a few other competing proposals if I remember.

So how non-DNSSEC keys are still being debated on, we decide to at least
take the KEY RR out of the running and leave the subject of securing DNS
separate than using DNS to support other security transactions.

Scott

---

From: "Andy W. Barclay" <[email-masked]>
Date: Tue, 02 Jul 2002 12:24:45 -0700

>>importantly, name-to-address and address-to-name mappings).

I disagree. RFC 2535 is very clear on this point, as I was reminded
a few weeks ago when I questioned why we bother with DNSSEC at all.

|    Keys associated with DNS names can be retrieved to support other
|    protocols.  Provision is made for a variety of key types and
|    algorithms.
`----

> irrelevant portions), it's the subtyping problem.

Yes, this could be a problem, IF you have a lot of keys at one name.
I envision that additional names will be created for most
applications. If we assume 1k per key (which I don't feel is 
unreasonable, but I could be wrong here), then we can store 
approximately 60 keys at a single name before we overflow.

> single APPKEY TYPE also propose to use the magic label approach.

Neither of these is necessary if we can live with the 60 keys per DNAME
restriction. I don't think this is overly-restrictive. Its just like we 
all deal with limitations on number of type A RRs associated with a name
so that the query/response doesn't fall over into TCP which a huge 
number of name servers would fail on anyway (cause silly admins block TCP).

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

Give a small boy a hammer and he will find that
everything he encounters needs pounding.
    --ABRAHAM KAPLAN

---

From: Rob Austein <[email-masked]>
Date: Tue, 02 Jul 2002 16:45:07 -0400

> |    protocols.  Provision is made for a variety of key types and

The WG said a great many things in RFC 2535, some of which have held
up better than others under further scrutiny as the WG has continued
its attempts to understand the problem space.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 3 Jul 2002 00:05:47 +0200 (CEST)

> single APPKEY TYPE also propose to use the magic label approach.

one could use a naming based on napstr, that would remove the magic label
approch for appkey but move it to a reference inside an naptr instead.
perhaps something like:

 host.example.com. NAPTR 1 10 "p" "APPKEY+ipsec" "" ipsec.host.example.com.
 ipsec.host.example.com. APPKEY ...

	jakob

---

From: Robert Elz <[email-masked]>
Date: Wed, 03 Jul 2002 10:24:30 +0700

Date:        Tue, 02 Jul 2002 12:24:45 -0700
    From:        "Andy W. Barclay" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I disagree. RFC 2535 is very clear on this point, as I was reminded
  | a few weeks ago when I questioned why we bother with DNSSEC at all.
  | 
  | |    Keys associated with DNS names can be retrieved to support other
  | |    protocols.  Provision is made for a variety of key types and
  | |    algorithms.

That says that you can use the KEYS that exist for other protocols
if you feel inclined.   It doesn't say that you can add new ones for
some other purpose...

The variety of key types, etc, is in case DNSSEC needs/wants to change
the algorithms it uses for securing the DNS.

  | Yes, this could be a problem, IF you have a lot of keys at one name.

The only way to avoid that is as Rob Austein said - magic names, or
different types.   Magic names are absolutely the wrong way to use the
DNS - the namespace there is to be allocated to the end user organisations
to use as they see fit, not to constrain for protocol purposes.
(You can see that I have one of the opinions that Rob mentioned...)

  | Neither of these is necessary if we can live with the 60 keys per DNAME
  | restriction.

That means < 30 applications max (to allow each to have a current, and
a past, key visible).   That's a very very low limit.

And ...

[email-masked] said:
  | one could use a naming based on napstr, that would remove the magic
  | label approch for appkey but move it to a reference inside an naptr
  | instead. perhaps something like:

That isn't a solution, it is the problem itself.   That's exactly what
needs to be avoided (for some particular cases it may be possible to
work that way, and NAPTR might happen to be one of those, keys certainly
aren't).

kre

---

From: Edward Lewis <[email-masked]>
Date: Tue, 2 Jul 2002 22:53:43 -0400

I don't intend this statement to be directed at any individual, but 
the following mail fragment is what prompted my statements below.

At 12:24 PM -0700 7/2/02, Andy W. Barclay wrote:
>>>I don't think application keys in DNS is "core DNSSEC functionality." The
>>>core DNSSEC functionality is protecting existing DNS data (most

I agree with Rob's and Randy's (not shown) thoughts on this thread.

Speaking as someone who has spent considerable time on DNSSEC, who 
co-chaired the BOF on SIKED, and was a closet proponent of A6, DNAME, 
and binary labels, I would say now that - to stay to the subject at 
hand - placing unadorned application keys in DNS is a mistake.

Way back before I spent time in the IETF, I developed a name server 
prototype.  The project I did this for is not historically 
significant, but I learned a lesson then that I had forgotten in my 
(later) formative years. (I have since relearned it from Randy at the 
SecDynUp workshop last winter).  Name service ought to be a simple, 
humble component in the machinery of a network.  Much like any 
central piece of a distributed system, the name service must be built 
to be rugged, flexible, and resilient.

Does this mean that the name service should not be secured, a la 
DNSSEC?  No.  Security is part of resilience.  But what I do mean to 
say is that putting a lot of extraneous features into the name 
service - just because it is there - is a patently bad approach. 
Sure, it is tempting to leverage on the service in place, but in the 
long run we wind up making the protocol more complex and worse, by 
putting all our eggs in one basket, create a more critical single 
point of failure.

RFC 2535 (and its predecessor) were wrong to promise that DNSSEC 
would be a fine way to distribute keys.  (I don't fault the editor, 
it was WG consensus at one time.)  Key distribution is a matter best 
left to the certificate working groups.  Why let the distributed 
database folks create another trust model when this is being done by 
security folks?  So what if there is unhappiness with what has been 
produced to date - those unhappy aren't going to do a better job than 
security experts.

I don't want to tie in the IPv6 record debate - that's another 
document, another thread, and a different last call.  But (I will 
because) the reason behind my distaste for this kind of DNS 
innovation is that these are (worthy) problems that ought not be 
solved in the DNS protocol.  What is needed is better (software) 
tools, applied in the right places.  These tools should do the work 
that is needed (learning trusted keys, managing renumbering of 
networks) and input the results of that work to a DNS server.  The 
DNS server should then simply distribute the data, and nothing more. 
Securely distribute - but only guaranteeing that what went into the 
master zone is what comes out the resolver.  No application security, 
just end-to-end transit security.

Keep the DNS simple.  Use it to locate other services.  Let other 
services update the DNS.  But don't make the DNS do too much - even 
if it is the path of least resistance.  Remember what the E in IETF 
stands for, it's not the "Internet Path of Least Resistance Task 
Force."  Fix what's broken, don't overload the protocol.  Complexity 
is a cancer.  Creeping features are a carcinogen.

So much for a soapbox statement.

As far as application keys, instead of trying to lump keys into the 
DNS, why not explore certificates?  They don't work?  Engineer them 
until they do.  By their very nature, certificates are the proper 
approach.  If it is because the tools aren't available - make the 
tools.  Don't break a fine protocol like DNS.

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

---

From: Greg Hudson <[email-masked]>
Date: 03 Jul 2002 09:50:38 -0400

On Tue, 2002-07-02 at 22:53, Edward Lewis wrote:
> approach.

Gosh, that's a strong statement.

I guess I'll just note that the current widely-known certificate
deployment has no key revocation infrastructure; as a result, bogus
certificates issued for Microsoft could not be revoked except by
deploying new software (with a hardcoded CRL) to every desktop.

I'm not sure that solving this problem is a simple matter of
"engineering certificates."  It may mean scrapping the whole concept of
an offline system.

> But what I do mean to say is that putting a lot of extraneous features
> into the name service - just because it is there - is a patently bad
> approach.

I continue to find this argument to be FUD.

For some applications, such as IPSEC, protecting the key of a host using
DNSSEC is not an "extraneous feature"; it's a core part of determining
that the host you're talking to is really authorized by the naming
authorities to use the hostname you wanted to talk to.  You could use
certificates for the same purpose (as we do today for web servers), but
it will always leave one with the nagging question of whether the
certificate authority agrees with the naming authority on who gets to
use what name.

Saying that DNS is being proposed "just because it is there" is a straw
man argument.  People have given perfectly good reasons to use DNS for
this purpose.

> These tools should do the work that is needed (learning trusted keys,
> managing renumbering of networks) and input the results of that work
> to a DNS server.

Agreed.  But I think the same technique can allow putting keys or key
fingerprints in DNS without adding complexity to the primary DNS serving
software.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2002 11:45:04 -0500

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?

I agree with you that adding *complexity* to DNS is a bad thing.   I just 
don't see how that premise directly supports the argument that there should 
be no keys in the DNS.   That is, adding *complexity* to the DNS is not the 
same thing as adding *records* to the DNS.   There is no reason why records 
have to be complex.

---

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

---

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

---

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

>  is a good thing. And the DNS looks like the "best" way to push

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

You already need EDNS0 to indicate support of DNSSEC.

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

> 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

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.

> validity, but not the cache's.  I'd expound further, but this isn't

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

---

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

>would need to implement the APPKEY RR, but that is conceptually no different

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.

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

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

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

>Any additional traffic caused by something like APPKEY would, I suspect, be

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.

>If your resolver would be able to handle such data, then I don't see the

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?

>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? ;)

---

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: "Jason Coombs" <[email-masked]>
Date: Mon, 8 Jul 2002 15:15:15 -1000

Aloha, Derek and Edward;

(I've enjoyed this discussion, thanks to both of you)

> Where keys-in-DNS helps is the first connection.  If you've
> 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.

This has already been mentioned, but aren't certificates a better
way to accomplish the application security you describe for that
first connection?

The attacker has another hoop to jump through in order to be an
attacker: they have to steal the secret key that corresponds to
the root certificate in the trust chain, or discover it through
successful cryptanalysis. This seems comparable to the additional
hoop required to spoof DNSSEC responses delivered to resolvers
in your proposed scenario.

The difficulty of mounting the attack is identical once the
server gets keyed and certified. So how does a key in DNS
increase the difficulty of an attack, exactly? By requiring
the attacker to hijack or spoof two boxes instead of just
one? Trivial if the attacker is already a full-fledged MITM.

If DNSSEC is deployed for the Internet as a PGP-style web of
trust rather than a DNS-style hierarchical distributed database
or an SSL-style centralized certificate authority trust model,
you still won't be able to trust anyone whose key is signed by
somebody you don't trust, and if you trust everyone who signs
keys then you essentially trust nobody all over again but you
just spent a whole bunch of time getting there.

I know this is old debate, at least in cryptographic circles.
My point is simply to caution against assuming more security
than you really have and suggest that it may in fact be
inappropriate (or at best useless) to view keys from DNSSEC
as anything other than applicable to DNSSEC as suggested by
draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. Some sort
of APPKEY may be valuable, but if it isn't for the purpose of
defining an Internet standard key service for some sort of
Internet standard cryptographic system like some type of
international smart card ID system and associated single sign
on service (*cringe*) then APPKEY seems to me to be of value
primarily for private, custom applications that don't need nor
do they benefit from the standards process.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Derek Atkins
Sent: Monday, July 08, 2002 1:29 PM
To: Edward Lewis
Cc: David Conrad; namedroppers
Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

-derek

---

From: "Derek Atkins" <[email-masked]>
Date: 08 Jul 2002 21:24:08 -0400

> way to accomplish the application security you describe for that

I wouldn't call it "better", but "different".  To be pedantic, DNSSEC
_does_ provide a certificate, by definition.  It's providing a binding
of a key to a name.  The only difference is that it's using the DNSSEC
key hierarchy instead of a non-DNSSEC key hierarchy for the
chain-of-trust.  But technically you do get "certificates" from
DNSSEC.

> in your proposed scenario.

The attacks against X.509 Certs are the same as they are against
DNSSEC, and vice versa.  Any attack you can mount against DNSSEC can
be mounted against a CA.  The real difference is that theoretically
you should be less successful with a real CA.  I say theoretically
because, well, "Verisign's Microsoft Certificate".

> one? Trivial if the attacker is already a full-fledged MITM.

Let's look at the SSH protocol..  The first time a clien connects to a
server, the server sends its key and the user is asked whether to
accept it.  If, however, the client makes a DNSSEC query for
<serverhost> IN APPKEY ..   and receives:

        <serverhost> IN APPKEY ...
                     IN SIG (APPKEY) ...

So, if the client compares the key from DNS against the key obtained
from the server, they have a higher level of assurance in that key (if
they match) than just accepting it blindly.

The user has a level of assurance that the key data in DNS is the data
that the owner of the domain put into the zone file.  A MITM could not
insert or change this data in the DNS, because they wouldn't know the
DNS signing key.

Now, you could call into question the ability of the DNS operator to
manage the keys, but the same can be said for CAs.  Similarly, if you
say the MITM has access to the DNSSEC signing keys, that's the same as
saying they have access to the CA Signing Keys.  A rose by any other
name....

> draft-ietf-dnsext-restrict-key-for-dnssec-03.txt. Some sort

I believe you are mis-reading the restrict-key draft.  The draft is
just saying that the KEY RR should be restricted, not that the concept
of using DNSSec for KEY Distribution is flawed.  When I say 'key', I
mean the concept of a key (be it stored in a CERT, APPKEY, or FROZBAR
RR), not the "DNS KEY-RR".

-derek

---

From: David Terrell <[email-masked]>
Date: Mon, 8 Jul 2002 18:43:42 -0700

On Mon, Jul 08, 2002 at 03:15:15PM -1000, Jason Coombs wrote:
> draft-ietf-dnsext-restrict-key-for-dnssec-03.txt.

the dropping of all non-DNSSEC KEY records is non-controversial
because nobody wants to have to parse multiple KEY RRs _while_doing_
_DNSSEC_validation_, not because the idea that DNSSEC should not
be used for application keys has gained WG consensus.

-- 
David Terrell   | "If I had a nickel for every time I've seen a Usenet poster
Nebcorp PM      | slip in an ostensibly casual reference to how much smarter
[email-masked]    | he/she is than everyone else... why, I'd be able to throw a
wwn.nebcorp.com |party for all my Mensa buddies!" -- Miguel Cruz

---

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: Robert Elz <[email-masked]>
Date: Tue, 09 Jul 2002 13:47:29 +0700

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

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

If there were one group of application developers looking to make use
of a single APPKEY record, most likely no-one would care much more than
about all the other random records that people keep adding to the DNS.
That is there'd be a bunch of "Oh no, not another one" groaning, but
as long as the spec was reasonable, no-one would seriously object.

The problem is that the premise isn't true - what's needed is an APPKEY
for every application, not just one APPKEY RR.

That leads to one of three possibilities - the APPKEY RDATA identifies
the application - but that solution simply doesn't work at all.

Or there's a different APPKEY RR type for every different application.
That one would work fine, but now the groans above start to become more
like pained shouting.   The 16 bit RR type space is currently huge,
but if we start numbering applications out of it, it will soon vanish.
So, this one really doesn't scale either.

Or, we start creating magic names for applications, to live in the
DNS, and so start to reserve namespace, which should be the end user's
prerogative to assign.   That's ugly - no, it is truly foul (SRV managed
that, with protocols, of which there are a far smaller number than
applications, with the leading _ trick by pretending that no users would
ever actually want to assign names starting with an underscore).

That there is no clean scheme that allows APPKEY to work reasonably
(assuming anyone would want to use it - if there are no actual users,
implementing it would be easy...) is why there's so much push back against
this one in particular.

kre

---

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 09 Jul 2002 17:33:18 +0700

Date:        Tue, 09 Jul 2002 11:53:11 +0200
    From:        Simon Josefsson <[email-masked]>
    Message-ID:  <[email-masked]>

  | One RR per application is not needed.  Solving the problem with SRV
  | style naming work.

I'm not sure I belive that - I can think of cases where I am switching
between web servers, all HTTP, all port 80 (or any other similar setup),
but with a different key for each of them.

  | I don't buy that.  Allocating a RR number for each security related
  | IETF protocol is no problem.

If it were just one per protocol (in which case the RR name would
probably be better as PROTOKEY or similar) I might just accept that.
But when it can be one per application, which I think it probably needs
to be, I don't.   Even with protocols, it would help if we had an
unused RR type cleanup mechanism (other than atrophy) but we don't.

  | Yes, it is ugly.  How does that matter?  It solves the problem and I
  | don't see any _technical_ problem.  Can you translate ugliness into
  | something that will cause actual problems?

If the "magic" name is X, and I happen to have already delegated X to
some other organisation, there's no way I can stick any RR's at the X
label, as it belongs to someone else now.

Leave the namespace for delegations, the way it is intended to be used.

kre

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jul 2002 11:53:11 +0200

> the application - but that solution simply doesn't work at all.

One RR per application is not needed.  Solving the problem with SRV
style naming work.

OTOH, I think it would be nicer to have one RR per application because
it 1) doesn't use sub-typing which supposedly is bad and 2) it doesn't
move semantics from the RR type field into the owner name field.  The
latter is only cosmetic, and the former only a minor advantage.
Either solution would be fine.

> So, this one really doesn't scale either.

I don't buy that.  Allocating a RR number for each security related
IETF protocol is no problem.  It wouldn't be a problem even if the RR
type space was 8bit.  Compare EAP's 8bit mechanism field.  If only it
was easier to introduce new RRs, I think this is the way to go
actually.

> ever actually want to assign names starting with an underscore).

Yes, it is ugly.  How does that matter?  It solves the problem and I
don't see any _technical_ problem.  Can you translate ugliness into
something that will cause actual problems?  If not, I'd say the
argument isn't very good.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jul 2002 14:51:23 +0200

> but with a different key for each of them.

Hm.  I'm not sure I follow, why wouldn't the following work if the web
servers were called w1, w2 and w3, respectively?

w1           IN   A        1.2.3.4
             IN   NAPTR    1 10 "p" "APPKEY+ipsec" "" foo.keys
foo.keys     IN   APPKEY   MIIfoo=
w2           IN   A        1.2.3.5
             IN   NAPTR    1 10 "p" "APPKEY+ipsec" "" bar.keys
bar.keys     IN   APPKEY   MIIbar=
w3           IN   A        1.2.3.6
             IN   NAPTR    1 10 "p" "APPKEY+ipsec" "" baz.keys
baz.keys     IN   APPKEY   MIIbaz=

Or simpler but a little bit less flexible (see below):

w1        IN   A      1.2.3.4
w1._ipsec IN   APPKEY MIIfoo=
w2        IN   A      1.2.3.5
w2._ipsec IN   APPKEY MIIfoo=
w3        IN   A      1.2.3.6
w3._ipsec IN   APPKEY MIIfoo=

> to be, I don't.

Why would one be needed per application?  That doesn't make sense to
me.  Rather, I envision that various IETF security protocols would
write a profile document saying how keying material is stored in DNS.

If each application defined its own use, there is no point in
standardizing anything and this whole discussion is irrelevant.

> Even with protocols, it would help if we had an unused RR type
> cleanup mechanism (other than atrophy) but we don't.

The IANA registry can deallocate allocated but unused RR types.

Compare this to IP service ports, also allocated by IANA.  It is also
a 16 bit space.

> label, as it belongs to someone else now.

This isn't an issue if NAPTR is used.

If NAPTR is not used, why would you have delegated a domain like
_ipsec?  If you care about app keys in DNS, you revoke the delegation
and put your host IPSEC keys there instead.  If you don't care about
keys in DNS, you can continue to delegate the domain.  This isn't
really rocket science.

> Leave the namespace for delegations, the way it is intended to be used.

I am inclined to agree, but I still doesn't see any technical
arguments, only cosmetic ones.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2002 10:16:34 -0500

> ever actually want to assign names starting with an underscore).

Let's say I have a host, toccata.fugue.com, with sshd running on it.   So 
what's wrong with having an APPKEY hanging off of sshd.toccata.fugue.com?   
We don't currently use subdomains of hostnames - what's the conflicting use 
that we're ruining by doing this?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2002 10:23:59 -0500

> Leave the namespace for delegations, the way it is intended to be used.

No offense, Elz-san, but this is sounds like "the way I think it should be 
used," which isn't very constructive, since you are not the only one on the 
planet who uses it.   My  server's hostname is not a delegation.   It's in 
the namespace.   What do you mean, "the way it was intended to be used?"   
Who intended this?   This sounds like "if God had meant us to hack, he 
would have given us ethernet jacks in the backs of our heads."   Maybe it'
s true, but here we are hacking, without the USB jacks, so the argument isn'
t convincing.

---

From: Peter Koch <[email-masked]>
Date: Tue, 09 Jul 2002 17:36:28 +0200

> what's wrong with having an APPKEY hanging off of sshd.toccata.fugue.com?   

While applications nicely fit into the hierarchical model (as well as
e.g. interface names) ...

> that we're ruining by doing this?

... you can't tell for sure what a host is. How do you find the SSH key
for the host "fugue.com" in your example? How do you find the "WWW" or "FTP"
key?

-Peter

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2002 10:57:36 -0500

> for the host "fugue.com" in your example? How do you find the "WWW" or 

Why, you use the PTR record!

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, 
doesn't it?   So the appkey is going to be hanging off the appropriate 
subdomain of the CNAME.   This isn't a problem, other than that it might 
make the appkey lookup code a little more tricky - it's a Simple Matter Of 
Programming.

---

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

> 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: Ted Lemon <[email-masked]>
Date: Tue, 9 Jul 2002 11:28:26 -0500

> strings harmony department". Now your key's name would fall into their

Okay, I can see where this would be a problem in the case you describe.   
Everybody here who types "ssh mydomain.com" to lob in, please raise your 
hand?

I guess this would be a problem for people who set up "fugue.com" as their 
web server address instead of "www.fugue.com", though.   I never understood 
why that was such a great idea, but whatever.   So fine, the key has to go 
at _sshd.fugue.com.   Again, why's that a problem?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Jul 2002 14:10:17 -0400

At 10:44 PM -0700 7/8/02, David Conrad wrote:
>Again, I'm confused how this is particularly relevant to DNSEXT.

I wouldn't want to the WG to promote something that could do harm. 
(Answering why I think this is relavant - not arguing for the moment 
if the topic at hand would cause harm.  What was the topic again?)

>could be, is going to trigger a "spectacular meltdown".  What am I missing?

Meltdown in the sense of a successful attack on DNS would undermine 
the applications depending on the DNS.

>course, it will be less from the DNS server's perspective -- is that your

No.  When comparing an unsecured version of an application versus the 
secured version of the same application, more resources are needed. 
That's a given.

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

Presumably the data arrived at the cache and was valid at the time. 
(In addition, the source indicates that the TTL should be high - the 
data isn't supposed to change and the source doesn't want to be 
bothered much.)  Once the data arrives, why would the cache grow to 
be suspicious of it (barring other input).

>would appear to be the desired behavior, would it not?

That depends on the application.  Some might, some might not.  Let's 
just make the DNS the "least common denominator" to account for the 
varying needs.

>based load balancers are such complete failures.  Err, wait...

TTL's of 0 are approximating the "real-time" nature of DNS by 
suppressing caching, but load balancers are just speeding up 
processing.  Even if you are using TTL's of 0 you aren't getting the 
full benefit of being real-time, there's no way to compare which 
0-TTL's RR is "fresher."

---

From: David Terrell <[email-masked]>
Date: Tue, 9 Jul 2002 12:12:29 -0700

> implementing it would be easy...) is why there's so much push back against

Well, if we've already _got_ magic names, and they're aren't actually
SRV specific....

hostname IN A 10.0.1.1
_ssh._tcp.hostname IN SRV 0 0 22 hostname
_ssh._tcp.hostname IN APPKEY "magic gloop"
and associated SIG records.

I wouldn't require that the APPKEY record require a matching SRV,
to be sure; the usual port assumptions (or user configuration) can
be used.

-- 
David Terrell            | "... a grandiose, wasteful drug war that will never
[email-masked]             | be won as long as so many Americans need to 
Nebcorp Prime Minister   | anesthetize themselves to get through the day." 
http://wwn.nebcorp.com/  |  -Camille Paglia

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jul 2002 18:40:10 +0200

> strings harmony department". Now your key's name would fall into their

So what?  If you delegate away a critical zone, it is your loss.

Naturally the name "sshd." could be chosen differently so that people
normally don't have to revoke delegations to take advantage of this,
thus "_sshd.".

You can see from another angle too.  Consider that you trust the
Special Strings Harmony Department to handle keys better than
yourself, then you can delegate this responsibility to them.

> Did you say "2782"? OK, make it _sshd.fugue.com. But then we have this "_"

Please summarize the technical arguments from the debate so we don't
have to go through it again.  Did someone dislike the "_" character?

None of this applies if NAPTR is used, of course.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jul 2002 18:14:38 +0200

> for the host "fugue.com" in your example? How do you find the "WWW" or "FTP"

Huh?  In a DNS-centric world; a host is a domain name with at least
one IN A, IN A6 or IN AAAA record.

Given a name of a host, to find the SSH key you prepend "ssh.".  In
your examples, the answer to your question would be "ssh.fugue.com IN
APPKEY", "WWW.fugue.com IN APPKEY" and "FTP.fugue.com IN APPKEY",
respectively.  What's the problem?

I'm not saying prepending "ssh." is a good solution, but the only
argument against it presented so far seem to be design religious ones.

---

From: Randy Bush <[email-masked]>
Date: Tue, 09 Jul 2002 23:36:09 -0700

this discussion is about how to put app keys in the dns.  but there
is a different list for that.  using namedroppers is disenfranchisng
those who think the topic will be discussed there.  

randy

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jul 2002 21:14:26 +0200

Edward Lewis <[email-masked]> writes:

> I wouldn't want to the WG to promote something that could do
> harm. (Answering why I think this is relavant - not arguing for the
> moment if the topic at hand would cause harm.  What was the topic
> again?)

The topic was if the KEY RR should be made DNSSEC-only without
offering a transition path for people who want to use it for what it
was defined in RFC 2535 to support.

Some solutions:

1) State in the document that application keys in DNS is a bad idea
   and it is now forbidden to do this.

2) State in the document that applications should transition to
   APPKEY.  This would mean shipping it together with APPKEY, which
   could be made similar to what KEY is today (which I think it mostly
   is, or?).  The APPKEY document could be silent on if it is a good
   idea, how owner names are used or anything like that.  This would
   keep the status quo.

3) State in the document that applications should transition to CERT.
   This would mean releasing an updated version of the CERT RFC (which
   would be useful anyhow, it is unclear on several things) that adds
   a sentence that clarifies that it is OK to store unsigned
   structures within the RRDATA.

4) ?

---

From: Jim Reid <[email-masked]>
Date: Wed, 10 Jul 2002 01:23:45 -0700

>>>>> "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? Or what if prepending
the protocol name makes the overall domain name too long? 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.

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Jul 2002 01:27:24 -0700

>    structures within the RRDATA.

this are items for the siked effort.  this document should not try
to encompass that effort.

randy

---

From: "Jason Coombs" <[email-masked]>
Date: Tue, 9 Jul 2002 22:43:40 -1000

>   and it is now forbidden to do this.

Application keys in DNS may be a bad idea, period. Infosec best
practices say simplify and remove features if you want security.

The square peg round hole argument alone is strong, but combine
it with what we've learned about how to write secure software over
the last 20 years or so and I'm surprised there's even anything
to debate... Applications that use the KEY RR today for anything
other than DNSSEC are security-flawed for practical reasons if
not for cryptographic ones. Practical security, how security is
accomplished in practice, must be considered by this standards
working group or else it might as well make the Windows Scripting
Host a REQUIRED part of all DNSSEC resolvers.

Specialized key servers are a great idea. In practice, expecting
programmers and administrators to manage security for APPKEY as
long as they're already managing security for DNSSEC is a non
starter. These are different application domains and must be
secured as such. The DNSSEC architecture meets only a subset of
the needs of a generic key service. Keys for individual
authenticated identities, keys for transactions associated with
those identities, keys for short time periods, keys for long
time periods, keys for hashing, keys for encryption, keys for
verifying digital signatures, mechanisms to log every use of
a key, mechanisms to log no use of a key, options to store and
disseminate signed keyed hashes of files so that operating
system vendors and others can reliably distribute authentic
hash codes that can be used to detect the presence of
malicious code on compromised boxes, and server awareness of
successful key delivery are just some of the key service
features that should exist that are unlikely to ever occur
within the context of DNSSEC. Misappropriating DNSSEC because
it exists and can serve data applicable only to other
applications is no different than defining an XML Web service
to serve application-specific purposes according to a single
common standard. More importantly, HTTP servers exist and are
widespread. DNSSEC servers are few. The problem of insecure
DNS is acute, and anything that might hold up DNSSEC server
deployment must be killed. Otherwise we should be discussing
an XML Web service standard as the distribution mechanism for
DNSSEC RRs instead of specialized name servers using port 53.

I recommend no migration path or backwards compatibility for
non-DNSSEC uses of the KEY RR. And while anyone can do anything
they want to create custom implementations of DNSSEC, I don't
see it as productive to practical information security for the
DNSSEC to be adapted and extended as a generic key service as
part of the IETF standard. Spin off that functionality and
assign it a new port number. Don't clutter DNSSEC with
unrelated APPKEY functionality.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Simon Josefsson
Sent: Tuesday, July 09, 2002 9:14 AM
To: Edward Lewis
Cc: David Conrad; namedroppers
Subject: Re: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-03.txt

Some solutions:

4) ?

---

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

Jim Reid <[email-masked]> writes:

> 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 12:53:16 +0200

> to encompass that effort.

As the restrict-key-for-dnssec document currently reads, it choses 1)
above but only implicitely.  Thus the document takes a stand in the
siked discussion by forbidding the use of KEY for that purpose.

---

From: Jim Reid <[email-masked]>
Date: Wed, 10 Jul 2002 04:55:26 -0700

>>  Well what if I had a host called ssh.fugue.com?

    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.

---

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

> 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: Robert Elz <[email-masked]>
Date: Wed, 10 Jul 2002 19:38:29 +0700

Date:        Tue, 9 Jul 2002 10:16:34 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | We don't currently use subdomains of hostnames - what's the conflicting use 
  | that we're ruining by doing this?

Says who?   We currently put "hostnames" anywhere in the DNS tree that
we like.

[email-masked] said in a different message:
  | No offense, Elz-san, but this is sounds like "the way I think it
  | should be  used," which isn't very constructive, since you are not the
  | only one on the  planet who uses it.   My  server's hostname is not a
  | delegation.   It's in  the namespace.   What do you mean, "the way it
  | was intended to be used?"    

If the namespace was delegated to you, it should be your choice how you
use it.   If you don't want your server's hostnames to be delegated, or
to have delegated sub-domains, or whatever, that's your choice, as it
should be.

Just stop trying to tell everyone else that they're required to assign
names, and perform delegations in the way that you believe it should be
done - every domain name owner gets to decide this for themselves.

And that includes sticking _'s anywhere in any domain name that they like.
And almost any other character.

The only restrictions are that the names not violate the rules of the
protocols in which they're used (the DNS's rules relate to lengths, and
no more, other protocols have other rules).

If I want to do

	example.com.		IN	MX	_sshd.example.com.
	_sshd.example.com.	IN	NS	some.random.other.site.

Then that's what I should be allowed to do (regardless of how stupid
that you believe it is, it is legal, and there are reasons for doing
just this - if perhaps not that particular name).

No-one should be defining away the namespace to make that cause things
to fail.

kre

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Jul 2002 05:56:46 -0700

> above but only implicitely.

no it does not.  saying don't use A for X does not in any way imply
don't do X

randy

---

From: Dan Massey <[email-masked]>
Date: Wed, 10 Jul 2002 11:09:29 -0400

> no it does not.  saying don't use A for X does not in any way imply

If  I say don't use the A record for IPv6 addresses,  that does
not implicitly mean that IPv6 addresses don't belong in the DNS.

Key restrict says don't use the KEY record for application keys.
That does not implicity mean application keys don't belong
in the DNS.    In fact, the draft explicitly states:

> The scope of this document is strictly limited to the KEY record.
>  This document prohibits storing application keys in the KEY record,
> but it does not endorse or restrict the storing application keys in
> other record types.

Dan

---

From: Derek Atkins <[email-masked]>
Date: 10 Jul 2002 11:31:55 -0400

> No-one should be defining away the namespace to make that cause things

Nobody is proposing any such thing.  Nobody is making restrictions on
what you _can_ do.  However, this is a proposal just that "if you want
to do FOO, do it _this_ way" in order to be compatible with everyone
else.  This is NOT the same thing.

If the proposal for "if you want to store an SSHD key in DNS, you
should prepend _sshd to the hostname" goes through, you can still do
what you want as your suggest, but you just will not be able to store
SSHD keys in DNS following the convention.  But that is perfectly
within your right as a zone operator to not follow conventions.  It
just means your zone wont play with existing applications that use
those features.  If you don't want to provide those features, you are
well within your rights to make that choice.

-derek

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Jul 2002 11:18:57 -0500

> 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.   :
'}

---

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

---

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.

---

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

---

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

> 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: Simon Josefsson <[email-masked]>
Date: Wed, 10 Jul 2002 21:22:35 +0200

> not implicitly mean that IPv6 addresses don't belong in the DNS.

If A records was designed to hold IPv6 addresses, and was the only way
to store IPv6 addresses in DNS, and it later became deprecated for
specifically that use only, it seems to me like a pretty clear message
that IPv6 addresses should not be in DNS.

>> but it does not endorse or restrict the storing application keys in

Yes, and that text together with my reasoning above confused me.

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Jul 2002 12:33:14 -0700

> that IPv6 addresses should not be in DNS.

there are 42 interesting proposals for storing IPv6 addresses in the DNS.
this draft would be foolish to choose sides.  it would merely move those
non-terminating discussions into this simple draft.

randy

---

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

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