Subject: Re: the KEY debate

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Aug 2002 12:04:40 -0700

I would just like to interject at this point that if the WG's goal is to 
find the *best* way to put keys in the DNS, we are doomed to fail.   The 
best is the enemy of good enough.   The KEY record was not good enough, and 
I think there's consensus on that, but we will never find out what the best 
is if we don't come up with something that's good enough, try it, and learn 
from it.

--
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: Jakob Schlyter <[email-masked]>
Date: Mon, 5 Aug 2002 09:31:24 +0200 (CEST)

On Mon, 5 Aug 2002, Ólafur Guðmundsson wrote:

> The best the DNSEXT working group right now is to help application
> people to draft proposals that suite each application needs.

I though for some time that a unified approach like appkey was the way to
go, but I've come to the conclusion that it was a bad idea and that we
really should take the time and work to defined new RR types for the
protocols needing this kind of mechanism.

the number of protocols that is a potentional user of appkey has been few.
in fact, I have not seen any other protocols except SSH and IPsec/IKE that
would fit the appkey model and even for these two protocols the
requirements for a RR type differs a lot if you would do them separately.

Wes Griffin and I have written a draft (and code) on how to verify SSH
host keys using dnssec and will publish it shortly. I suggest that people
interested in doing this for IPsec does that same.

	jakob

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Aug 2002 15:25:31 +0000

> SIKED BOF showed us that "unified" approach will not work (IMHO) as the
> "security mafia" will demand (rightly so) a solid security consideration
> section that covers all applications (a NP complete task).

ah.  that is of course ridiculous, but it's nice to know that the reason
we can't complete the debate on restricting KEY is due to ridiculousness
from outside DNSEXT.

> The real reason I think the separate RR type approach is the best one,
> has to do with dynamic update of application key information.  E-mail
> keys will be updated by the email administration people, IPSEC keys by
> the remote access group, etc.  It is much simpler to grant authority
> to update a single type for, existing names than allowing the
> creation/deletion of SRV style name such as _sec._ip.<name>

had that but been proposed, then we could be discussing it.  i however am
ready to see _pgp._key.<name> or even _pgp.<basename>._key.<parent> or
_key.<basename>._pgp.<parent> if that is what it would take to get motion.

> people to draft proposals that suite each application needs.

if you want to see more botched rdata encodings and more dns-hostile designs
along the lines of say GPOS or NIMLOC or (dare i say it?) NAPTR, then by all
means push this activity outside of DNSEXT where it can fail.

i on the other hand would much rather see success, both for DNSSEC (if you
call its best remaining destiny a success, which i'm capable of) and for all
the "appdev" folks who just want a place to put their security goo other
than $HOME/.gpg and $HOME/.ssh.  i think it is reasonable for these folks
to oppose the restriction of KEY unless and until there's visible progress
made on CERT or APPKEY or some kind of TXT with SRV-like naming or even a
series of different RR's, on a per-security-system basis.

(ultimately i expect the debate to be closed rather than completed, which is
my own private cause for sadness about the "key-restrict" draft.)

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 5 Aug 2002 22:08:08 +0200 (CEST)

On Mon, 5 Aug 2002, Paul Vixie wrote:

> if you want the community to support the restriction of KEY to just
> DNS's own security needs, then you will have to put a replacement on the
> table, and i mean give these people a fish, don't just teach them how to
> fish.

I believe these "people" are SSH and IPsec.

since there is no deployed code using key for SSH, noone will complain
from that side. IPsec on the other hand has deployed code.

my understanding is that opportunistic IPsec uses, our could use, more
information (such as security gateway address) than are availible in KEY
and therefore need some additional data anyway (TXT, KX, ...).

if "people" would get started on writing a draft describing the thing they
actually need we might get somewhere instead of discussing key-restrict
for six more months.

	jakob

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Aug 2002 22:44:53 +0000

> ... since there is no deployed code using key for SSH, noone will complain
> from that side. ...

i wish i shared your confidence.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Aug 2002 13:01:16 -0400

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

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:
    Mark> 	We have basically already made a decision about whether we
    Mark> 	should have different type or not for application keys.
    Mark> 	DNSSEC is one application and the decision was made to
    Mark> 	give it its own type by removing the other uses.

  "we", being whom? 
  I do not agree that there is any consensus on this.
  I will agree that there is some concern with KEY records at the APEX. 

  The problem was raised in Salt Lake City. 

  It would be nice to ask for a specific sub-type, but frankly, I don't care.
Sorting through the types isn't that big of a deal. Given the sizes of the
resource records and the desired presence of DNSSEC, the answers may well be
large already.

  I was unable to attend the SIKED BOF. The reports that I heard indicate
that a small number of people who hadn't actually read any of the drafts that
specify KEY did a bunch of handwaving on how there was no trust model. 

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Aug 2002 08:41:29 -0400

At 9:47 PM -0400 8/6/02, Michael Richardson wrote:
>   The offer was made. I was not placed upon the agenda, as we had a very well
>developed draft that you could read.

I asked but got no reply:
     http://www.cafax.se/keydist/maillist/2002-02/msg00002.html

Since you already had a draft, OE wasn't listed on:
     http://www.cafax.se/keydist/maillist/2002-01/msg00112.html
or
     http://www.cafax.se/keydist/maillist/2002-01/msg00170.html

Had you offered to be on the agenda, we would have liked you to be. 
I guess we weren't clear enough, at least not in a public forum.

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

True, and you have been active on the keydist list.  (I've dropped 
off it for various reasons.)  As far as affecting progress, it's hard 
to say, but without a voice in the room to defend the effort from 
yet-another-angle, momentum for the effort was adversely affected.

BTW, there's no official "death certificate" for SIKED, and it is 
eligible for another BoF - it just needs folks that are willing to 
pull it off.  I think the chairs of the BoF would be willing to pass 
chair-ships onwards. ;)

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Aug 2002 09:04:51 -0700

The problem with the SIKED BOF is that the organizers had a preconcieved
notion of their solution and platform.

The reason that there was little interest in the SIKED approach is that
there is already an Open Working Group that is developing a key centric PKI
that provides a superset of the proposed SIKED functionality with much less
complexity called XKMS.

XKMS is supported by all the major PKI vendors and many others. It is an
important part of the infrastructure being developed to support Web Services
Security.

The IETF has spent ten years each developing PKIX and DNSSEC. There is no
likelihood that SIKED or anything like it will complete in under three
years. Nor after the DNS Directorate/OPTIN debacle can the IETF claim any
particular credibility as an open standards organization over W3C or OASIS.

This group has no business making proposals for general purpose PKI
infrastructure until it has proposed a deployable infrastructure to support
DNS itself.

	Phill

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 15:06:59 -0500

on 8/7/2002 3:00 PM Jakob Schlyter wrote:

> and when you've added redundancy, security and a couple of other nice
> properties you've suddenly almost built that other DNS and called it LDAP
> instead.

redundancy is in there. security is a vague property, but TLS is in there.

what LDAP lacks is what makes DNS useful, which is lightweight datagrams
and caching, to name two.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Aug 2002 16:01:38 -0500

> Well-know fact that excess RRs bound to an owner will cause overflow of
> UDP queries for qtype ALL. Adding "just one more" RR to a set means that
> all first-pass queries for an overloaded owner name fail.

So what?   Which applications, other than dig, look up qtype ALL?   Are 
these applications doing the right thing?   I.e., is it the idea of putting 
more records in the DNS that is broken, or is it the applications that use 
qtype ALL when they probably don't need all the data?

> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful.

This is a good argument for srv-style records, but it's not a good argument 
for not putting keys in the namespace.   I don't think there should *be* a 
dozen keys hanging off a single name - as you say, ETOOMUCHINFO.

> Cache overflow is already common in large ISPs.

Can you add a little more to this statement?   By itself, it could mean 
"most ISPs don't make their caches big enough," or "lots of trash falls out 
of the cache, improving performance," or "we have a real problem."   You 
seem to be saying that it's the third option, but you haven't said anything 
to support that interpretation.

Furthermore, the biggest DNS problem I'm aware of right now is misdirected 
queries.   If these are what is thrashing the typical ISP's cache, that's 
completely orthogonal to the question of what or how much data should go in 
the DNS.

---

From: "Jason Coombs" <[email-masked]>
Date: Wed, 7 Aug 2002 11:25:38 -1000

Derek,

Neither SSH nor IPSec should ever be used to conduct secure communications
with arbitrary dynamically-discovered third parties, so your examples don't
make much sense to me.

Better for you to KNOW the keys needed, in advance, to secure communications
with trusted hosts that you have an SSH or IPSec relationship with. Why do
you want to discover them dynamically? In particular, why would you EVER
want to discover them dynamically *across domains* ? That's just asking for
trouble and it's a feature without a purpose. It might also be deficient in
the area of common sense.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]
Sent: Wednesday, August 07, 2002 10:53 AM
To: [email-masked]
Cc: David Conrad; Eric A. Hall; Scott Rose; namedroppers
Subject: Re: [Design] Re: the KEY debate

"Jason Coombs" <[email-masked]> writes:

> > Can we _PLEASE_ stop with this FUD?
>
> There IS a valid infosec perspective within this FUD.
>
> Adapting DNS to distribute keys for applications other than DNS creates a
> single point of security failure that impacts many applications instead of
> just one, and that's bad.

This is why I stated that it is a niche, only for applications that
understand the implications.  It is _NOT_ a general solution -- it is
a general framework for a couple of specific solutions (e.g. SSH and
IPsec).

I think the players well understand the implications involved.  Note
that using X.509 certificates is not necessarily any better
(c.f. Verisign's "fake" Microsoft certificate).  There are not
additional issues using DNSSEC for security, they are just wearing
different colors than the same issues in other venues.

You can only push those issues off so far until _somebody_ needs to
address them (or not, as the case may be).

-derek

PS: I think the proponents of "application keys in dns" are trying to
get "good enough" security as opposed to "world-class, military grade
security".

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 16:45:15 -0500

on 8/7/2002 4:01 PM Ted Lemon wrote:

> "most ISPs don't make their caches big enough," or "lots of trash
> falls out of the cache, improving performance," or "we have a real
> problem."   You seem to be saying that it's the third option, but you
> haven't said anything to support that interpretation.

What I'm saying is (d) the more crap we stick into DNS, the more caches
will overflow, making the service less useful

---

From: David Conrad <[email-masked]>
Date: Wed, 07 Aug 2002 15:03:23 -0700

> will overflow, making the service less useful

Sorry, I don't get this.

If the cache is filling up, it is because it is being used for something.
This would seem to me to imply that it is being more useful.

What am I missing?

Rgds,
-drc

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 16:57:34 -0500

on 8/7/2002 4:46 PM Jim Reid wrote:

> So why hold back DNS progress -- if that's what putting keys into the
> DNS is -- because it might make naive users do stupid or bad things?

Just for the record, I didn't mention keys, and I stayed out of that part
of the debate. I am opposed to them in principle but I also realize that
the other camps aren't giving up on it, and there isn't a viable
alternative. My message was meant to suggest that we should be working on
those alternatives so that there is somewhere else to put this stuff.

>     Eric> Adding a bunch of 4k RRs to an owner can exceed TCP capacity.
>
> Sorry, I just don't understand this. When did TCP (or name servers)
> have a problem transferring more than a few Kb?

The TCP size field is a 16-bit value, meaning that a message has a maximum
capacity of 64k.

---

From: Jim Reid <[email-masked]>
Date: Wed, 07 Aug 2002 15:42:57 -0700

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:

    Derek> Jim, Eric is right that DNS messages are limited to 64k
    Derek> (even with TCP).

Indeed. I got the context wrong: Even so, I don't understand the point
Eric was making. How does a response that's comprised of more than 1
DNS-over TCP 64k message cause a problem?

---

From: Brian Wellington <[email-masked]>
Date: Wed, 7 Aug 2002 16:05:47 -0700 (PDT)

> DNS-over TCP 64k message cause a problem?

Last time I checked, DNS didn't specify a mechanism for multiple messages 
in a response.  EDNS1 doesn't count.

Brian

---

From: [email-masked]
Date: Thu, 08 Aug 2002 10:11:21 +1000

> in a response.  EDNS1 doesn't count.

	Actually it does.  It's called AXFR.  No clients currently fall
	back to AXFR but it could be done.  The few truncated TCP responses
	I've followed up have all been for PTR record as a result of SPAM
	from porn sites.  I've never seen the need to implement the fallback.

	As for DNS caching strategies, I'm sure they will evolve as needed.
	BIND 9 uses random drop at present.  We could also add different
	max-cache-ttls depending upon rdata set size.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Aug 2002 11:06:13 -0700

I don't think that the allegations of FUD are justified, however it is clear
that this group does not have a clear understanding of the security issues
surrounding key distribution.

Single point of failure sounds scary, however that is not the main reason
why it is a canonically bad idea to reuse DNS as a key distribution system.

The real problem is that DNS is designed operated and deployed as a name
infrastructure. The majority of the DNS servers are deployed without any
form of security analysis. Only a small number of TLDs have a comprehensive
security profile in place.

It is a very bad idea to make a change in a deployed protocol that changes
its status from a non-security infrastructure to a critical security
infrastructure.

>From a technical point of view it is quite possible to integrate a Kerberos
style key distribution mechanism into DNS and if DNS was being designed from
scratch that is exactly what I would propose. However retrofitting any type
of primary key distribution scheme into a deployed service is completely
unacceptable.

There is a solution to this problem.

		DNS -> SRV -> XKMS

		Phill

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2002 13:53:45 -0500

> its status from a non-security infrastructure to a critical security

If this statement is true, then DNSSEC is a bad idea.   The whole point of 
DNSSEC is to be able to authenticate the answers that the name server gives.
    This is done using a secret key.   Compromise of that key allows the one 
who has compromised it to claim that invalid data is valid in a way that 
can be cryptographically authenticated.

So if you use DNSSEC, the DNS server *is* part of the critical security 
infrastructure.   There is no getting around this.   Once that genie is out 
of the bottle, it doesn't make any difference how many keys you store in 
the DNS, because you *have* to treat the DNS server as part of your 
critical security infrastructure.

BTW, please note that nobody is saying here that DNS should take the place 
of Kerberos or something like it.   Rather, what is being said is that 
there are applications where making a key available in the DNS makes sense.
    For example, an SSH host key can be used to verify that you are talking 
to the host associated with an A record that you've looked up.   This doesn'
t grant you access to the server - your private key does that.   What it 
does is to simply verify that you are talking to who you think you are 
talking to.   For this kind of security, storing keys in the DNS makes a 
lot of sense (to me, at least!).

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Aug 2002 12:36:10 -0700

Your post makes two comparisons which are both inappropriate.

First the adding of security to the DNS protocol to secure DNS cannot and
should not be conflated with the use of DNS infrastructure to secure other
protocols.

Then you say nobody is proposing X and go on to propose X.

		Phill

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, August 08, 2002 2:54 PM
> To: Hallam-Baker, Phillip
> Cc: namedroppers

---

From: [email-masked]
Date: Fri, 09 Aug 2002 08:01:26 +1000

> At 6:23 PM -0400 8/7/02, Derek Atkins wrote:
> >Jim, Eric is right that DNS messages are limited to 64k (even with
> >TCP).  Perhaps EDNS1 can fix this (I don't know if EDNS0 does
> >offhand).
> 
> I doubt that there's a way to fix the size limit.  In TCP, you lead 
> with a two byte length field not present in UDP.

	It's easy enough to fix this.  The problem is how long after
	you deploy code to fix the problem before you can you reasonable
	expect to be able to use the new code.

	Mark