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

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

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

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

> 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: Edward Lewis <[email-masked]>
Date: Tue, 9 Jul 2002 14:10:17 -0400

At 10:44 PM -0700 7/8/02, David Conrad wrote:
>On 7/8/02 2:09 PM, "Edward Lewis" <[email-masked]> 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?)

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

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

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

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.

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

>>  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?
>
>If someone has made their key validity period be 120 seconds, then that
>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.

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

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

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

---

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