Subject: the KEY debate

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Aug 2002 13:17:36 -0400

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

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Loomis," == Loomis, Rip <[email-masked]> writes:
    Loomis> First, I agree with Matt's recommendation to take the
    Loomis> discussion to namedroppers...but as another way to state what
    Loomis> Matt already stated quite well above, it's not that having
    Loomis> lots of non-DNSSEC info in KEY records "breaks DNSSEC".  It's
    Loomis> that having to sort through all the possible cruft at the top
    Loomis> of a zone and look for the "right" key causes the DNSSEC
    Loomis> signature verification process to take too long.  There's not
    Loomis> much IMHO that can realistically be done to engineer either
    Loomis> the software or the protocol to fix this...other than limiting
    Loomis> the KEY record as that I-D discusses, and using APPKEY or
    Loomis> something similar to store the non-DNS application keys.

    Loomis> If anyone sees any holes in my summary above...ask me on
    Loomis> namedroppers.

  Let's be clear.

  Some people who are not application developers, and who have no deployed
code, want to obsolete KEY EVERYWHERE for non-DNS use because they think that
it might cause problems if put at the apex of a zone.

  Who wants to put non-DNS KEY records at the apex of a zone?

  What application needs it there?

  1) IPsec.	   nope, needed with host records or reverse records.

  2) SSH/telnet.   nope, same requirements as IPsec.

  3) HTTPS.	   maybe for supporting "example.com" as an alias for
		   www.example.com, but due to HTTPS limitations, would
		   require a seperate IP address from www.example.com
		   (so that the server could use the proper certificate)
		   A major hassle, and it is unlikely that this is going
		   to matter as long as we do web certificates with X.509
		   CAs.

  4) SMTP.	   Put an MX record there. Use the KEY record attached to
		   the MX record, and authenticate the server. You might
		   think that you want to authenticate the zone's key, not
		   the server's key. Well, that doesn't work, because you
		   don't know which of potentially many MX servers you will
		   talk to. You could give them all the same private key,
		   but that would be a mistake, given that for best
		   reliability, you want the MXs in different places, run
		   by different people.

  So, we are left with someone who wants to do:
      "ssh example.com"

  rather than 
      "ssh host1.example.com"

  Of course, they might put 100 A records at "example.com". Will DNSSEC deal
with this? Will it be cause the signature verification process to take too long?

Massey/Rose write:

>differences in more detail.  Combining these very different types
>of keys into a single sub-typed resource record adds unnecessary
>complexity and increases the potential for implementation and deployment
>errors.  Limited experimental deployment has shown that application
>keys stored in KEY records are problematic.

Also, they write:

>The following table summarizes some of the differences between DNSSEC
>keys and Application keys:
>
> 1. They serve different purposes.
>
> 2. They are managed by different administrators.
>
> 3. They are authenticated according to different rules.
>
> 4. Nameservers use different rules when including them in responses.
>
> 5. Resolvers process them in different ways.
>
> 6. Faults/key compromises have different consequences.

#1 is confused about the purpose of DNS. DNS serves to map names into things
that the network layer can use to connect with. 

DNS is to permit people to type "telnet host1.example.com" and have it
work. In an age of SECURITY, that means that we all of the network blobs
required to make that connection. 

These are *not* APPLICATION keys because "telnet" is not an application, it
is a session layer protocol. Emacs is an application. Word is an application.

#2 is also confused when it comes to IPsec and SSH keys.
IP addresses are FREQUENTLY managed by the same people who manage the hosts
that they are assigned to. Even when protocols like DHCP is used to assign IP
addresses, we have demonstrated that making the link to the public key can be
done at the same time. There are two WGs that want to leverage this kind of
thing.

They further list #3 - that keys would be exchanged with the parent zone.
DS gets rid of that, so this comment is moot.

#4 is a concern - but, you MAY NOT deprecate a facility without having
provided a replacement facility. The SRV and NAPTR suggestions are
unacceptable, as they introduce yet another round trip. There are only two
methods which will work:
      1) special names. "ipsec.example.com" - might as well use	KEY.
      2) a RR for each application.

Claim #5 is totally confused. They keep saying how application keys must not
be used to authenticate data. They then go on to explain how writing
application is "hard" because we might have to do DNSSEC ourselves. Not only
do want to do that, but we *insist* on doing it.

Claim #6 is again totally confused. Where does it say that application keys
are used to authenticate DNS data?

In general, we regard this draft as a denial of service attack on the effort
to secure the Internet. 

]       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"); [

		   

--
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: Rob Austein <[email-masked]>
Date: Sat, 03 Aug 2002 14:50:39 -0400

I know I'm going to regret this, but....

There is a specific problem with using the KEY RR type for things
other than DNSSEC's own internal keying.   It's called the "sub-typing
problem" and has been discussed namedroppers many times before, please
check the archives if you don't already understand the problem.

This is a totally separate discussion from whether putting keys for
things other than DNSSEC itself into the DNS is a good or bad idea.
If we stipulate that such keys should use a different RR type, I'm
relatively agnostic on the subject.

Confusing the two issues does not help anybody.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 03 Aug 2002 21:43:39 +0200

> Confusing the two issues does not help anybody.

Agreed.  But removing functionality does not help anybody either,
that's why I suggested shipping restrict-key draft together with a
migration path in the form of APPKEY, an updated CERT RR
specification, or a specification stating that applications should
define their own RR for keying material, or whatever approach is
preferred by the DNS illuminati.  Then the restrict-key people are
happy, and the application keys in DNS community is happy.  Why is
that solution unreasonable?

---

From: Rob Austein <[email-masked]>
Date: Sat, 03 Aug 2002 18:21:13 -0400

> that solution unreasonable?

If the two halves of this proposal were at equal stages of readiness,
this would be a reasonable way forward.  Unfortunately, they're not:

- The reasons for updating the DNSSEC protocol spec to restrict use of
  the KEY RR type to DNSSEC internal use have been well understood for
  years, the DNSEXT WG is actively trying to get the updated DNSSEC
  spec done and the protocol deployed, and from the DNSSEC core
  protocol persepctive, there's no reason to delay updating the spec.

- The APPKEY/CERT/whatever stuff isn't as far along.  No doubt you
  recall the SIKED BOF this year in Minneapolis, at which several
  people asked some pretty fundamental questions about the problem
  spaces people were trying to solve and what the underlying trust
  models were.  No good answers at that time.  Not saying there
  -aren't- good answers, but at that BOF there didn't appear to be any
  kind of consensus on the subject.  So proponants of this idea have
  some work cut out that either has not yet been done at all yet or
  has been done but has not yet been walked through the IETF process.

Finally, given the above, I have to wonder who would really benefit
from delaying the cleanup action on the core DNSSEC spec until the
other stuff is done.

---

From: [email-masked]
Date: Sun, 04 Aug 2002 09:19:08 +1000

> that solution unreasonable?

	We have basically already made a decision about whether we
	should have different type or not for application keys.
	DNSSEC is one application and the decision was made to
	give it its own type by removing the other uses.

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

---

From: Dan Massey <[email-masked]>
Date: Sun, 04 Aug 2002 14:15:09 -0400

Hi,

I started a more detailed in-line response to the various claims
about key restrict but  the main points of this discussion remain
the same as the last couple times....

  - key restrict does not prohibit storing application keys in the DNS
    and key restrict explicitly states that in a couple places.

  - key restrict does say the KEY record should not be used to
    store application keys and it does eliminate KEY record subtypes.

  - subtypes are a bad way to overload a DNS record and there is
    consensus that a subtyped KEY record is not the right way to
     store applications keys in the DNS.

There is an orthogonal problem of  what is the best way to store
application keys in the DNS.  Key restrict does not identify one
approach as "the solution" for storing application keys, but note
that key restrict is 100% compatible with all the approaches being
discussed.  There are legitimate open issues and trade-offs being
considered and there are places to discuss those issues.

Dan

---

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.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 04 Aug 2002 19:40:59 +0000

> is if we don't come up with something that's good enough, try it, and learn 

the working group had better show some leadership, in that case.  saying that
KEY is wrong for applications due to subtyping is merely _true_.  let's try
for _helpful_.

1. subtype with subdomains that have leading underscores, like SRV does.
2. carry the key data itself in TXT RR's.

if someone writes up a draft showing how openpgp keys and x509 certs can
be carried in that fashion, then this whole debate will be over, because
you will have demonstrated some leadership.

until you do that, all you're doing is trying to take something away from
the "appdev" community, and they will fight you to the last binary digit,
regardless of the truth of your arguments.

---

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

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

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

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

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

	Mark

> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Finger me for keys
> 
> iQCVAwUBPU1d2YqHRg3pndX9AQFR7AP+JyjTi+mWqYOrSOOqsNXcD86y1EaRvyTR
> Jxf9hwNd+BLTkR7vDqZT8lRhIb3eX1dNhvI8u6YlOYqwx8yd44GZChdsu5INcgzE
> T5TK+350q+mU829HRSfxntKvmGN4HnmS8nQEZA2IYeUt1ZobRgrZcAXzM2BCvTT5
> 6pGsu2flF/E=
> =J88s
> -----END PGP SIGNATURE-----

---

From: Rob Austein <[email-masked]>
Date: Sun, 04 Aug 2002 20:13:44 -0400

At Sun, 04 Aug 2002 12:53:03 -0400, Michael Richardson wrote:
> 
>     Rob> There is a specific problem with using the KEY RR type for things
>     Rob> other than DNSSEC's own internal keying.   It's called the "sub-typing
>     Rob> problem"
> 
>   Yes, and obsoleting KEY does nothing to solve this problem.

Sorry, wrong.  (a) it removes the need for DNSSEC-aware resolvers to
sift through RRsets picking out individual keys by subtype codes, and
(b) it reduces the chances that KEY RRsets will be large enough to
trigger DNS message truncation and fallback to TCP.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 05 Aug 2002 01:41:50 -0400

>you will have demonstrated some leadership.

I real sorry to see the efforts of trying to define other ways to
carry keying information via DNS are not progressing.

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).
We need to see if application specific type approach will work as
writing a security consideration section for one particular 
application/protocol should be much simpler.

The other thing that needs to be addressed is that different applications
have different keying needs, some require Certificates, others require the
public key information, others can get away with a signed key footprint.

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>

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

         Olafur

---

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

> 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: Simon Josefsson <[email-masked]>
Date: Mon, 05 Aug 2002 11:59:17 +0200

> 	There is no shortage of types.  If we exhaust IN then we can

Actually KEY/SIG/NXT apparently isn't restricted to IN.  From
dnssec-records:

   The KEY RR is class independent.

   The SIG RR is class independent, [...]

The IANA DNS registration page should probably be updated, it says
KEY/SIG/NXT is for IN only.

Also, NXT doesn't provide authenticated denial across IN boundaries.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Aug 2002 08:51:18 -0400

>that solution unreasonable?

This is a philosophical answer.  So, if you have code to compile, 
take care of that and leave this for when you want to counter the 
effects of all that coffee and cola you've had today.

There is a good reason to restrict the use of the KEY RR.  The reason 
is that in doing so we can achieve a tighter definition of DNS 
security.  Having a tighter definition makes the security model 
clearer and more verifiable (in that it works, not in the sense that 
I can verify data).  Additionally, due to the implementation of DNS 
(I mean the protocol, not the software), if the KEY RR is 
unrestricted we can run into performance glitches (TC bit getting 
turned on).  That and the desire to put the KEY RR set in the 
authority sections when possible drive a desire to limit the size of 
the set.  Then, of course, there is the "fear" (as in FUD) that 
poorly implemented resolvers may not check whether the KEY RR flags 
and protocol field are properly set and misuse a key.  (Yes, FUD.)

Rob has already mentioned the "sub-typing" problem, and referred 
further discussion to the archives.

None of this addresses the application-keys-in-DNS issue.  Yes, 
currently the KEY RR can accommodate them (RFC 2535) and the 
KEY-restrict draft would stop this.  The reasons for the stopping are 
above, and should be clear in the draft.  (I've made comments to that 
effect already.)

In a perfect world (we wouldn't need DNSSEC, but) it would be good to 
be able to achieve both the restriction on KEY and provide an 
alternative for the application keys in one fell swoop.  In my 
opinion, this just can't happen.

First, one of my goof-ball ideas was that we should just completely 
ditch the KEY RR for DNSSEC altogether, replacing it with the DNSKEY 
RR and restrict DNSSEC processing to just that record type.  I really 
am leery of restricting an existing definition because there will 
always be code out there that implemented the unrestricted version of 
the definition.  Moving to a new RR type would eliminate the problem, 
but was shot down because the KEY restrict draft was already written.

Second, give that restrict key is on the threshold, it can be put in 
place to alleviate the burden placed on the DNSSEC definition now. 
Waiting for a solution to application-keys-in-DNS would be a delay I 
think we could do with out.  Partly because of my third point.

Third, there's no clear consensus on how to proceed with application 
keys in DNS.  I don't mean DNS* consensus, I mean any sort of a 
community consensus.  (How close are IPsec OE and SSH in agreement on 
how to approach this?)  For my part, I really think that it is a 
mistake to expect a generic application key solution to come from 
DNS, rather solutions should come to DNS.  (E.g., from the SSH WG or 
the IPSEC WG.)  Yes, solutions in DNS should get some DNS review, but 
the applications know better their needs and goals.  The solutions 
should also get some Security Area review, as the DNS community is 
not geared towards security issues (if we were, perhaps DNSSEC would 
be done by now).

Third and a half, I'm hesitant to support any application key 
approach that relies on the DNSSEC protections to cover delivery of 
the key material from end to end (e.g., server to client).  DNSSEC 
may be part of the solution (the DNS authoritative server to 
resolver) but is not the whole (e.g., requiring a client to allow a 
human user to inspect the fingerprint before blindly accepting is a 
good idea).

Fourth, this is the philosophical comment.  Waiting until there is a 
completely worked out design before going forward is a good way to 
design a bridge over a river, and is generally a sound engineering 
approach.  A converse example is the OSI protocol suite, especially 
the session layer protocol, which addressed every conceivable 
situation in theory and wound up with an unworkable implementation. 
Another example, much more philosophical, is a human society and the 
body of law applied to it.  No set of lawyers could ever think up 
every situation ahead of time, so it is sometimes best to partly 
define the law and let cases set precedents.

My point here is that there is sometimes value in partial 
definitions, especially when the next step to a complete definition 
is still unsettled.  Restricting the KEY RR (or defining my pipe 
dream of DNSKEY RR) accomplished a known, needed step.  Losing the 
application-key-in-DNS feature (or any feature) isn't a good thing, 
but there isn't a clearly good alternative.  I'd say let's not wait 
and hold the KEY RR restriction up while testing the best way to 
accomplish the needs of applications wanting to distribute their 
keys, possibly via DNS.

If you've made it this far, try counting sheep.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

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

> 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: Rob Austein <[email-masked]>
Date: Mon, 05 Aug 2002 13:25:58 -0400

At Sun, 04 Aug 2002 23:58:04 -0400, Michael Richardson wrote:
> 
>     Rob> Sorry, wrong.  (a) it removes the need for DNSSEC-aware resolvers to
>     Rob> sift through RRsets picking out individual keys by subtype codes, and
>     Rob> (b) it reduces the chances that KEY RRsets will be large enough to
>     Rob> trigger DNS message truncation and fallback to TCP.
> 
>   This argument is valid for KEYs at zone APEX only. 
>   DNSSEC only ever cares about KEYs that that point anyway.
> 
>   As I have said several times, there is likely little reason to ever have
> non-DNSSEC keys there. The only use is seeminly web servers, and the
> limitations on HTTPS for virtual hosting means that a single IP can not
> serve both both https://www.example.com and https://example.com. 
>   As such, it is very unlikely that such a KEY record would be placed.

Your analysis depends on simplifying assumptions about the location of
the zone cuts.  Not everyone agrees with your assumptions.

>   If we introduce a new RR for each use, then we can also solve the problem.
>   I prefer to introduce a new RR for each use. 

Oddly enough, we are in agreement on this.  I've been advocating using
separate RR types for this purpose for years now.  The usual
counter-argument is that it takes too long to deploy new RR types.  In
theory the recent work on how DNS implementations should handle
unrecognized RR types helps here; in practice, well, we'll see.

I don't have any particular attachment to the current KEY RR type
either, and strictly from a protocol standpoint I suspect that it'd be
better to dump it and use a new RR type for DNSSEC's own keys as well,
with (at least) the subtype field removed from the RDATA of the new
type (fields that don't exist doesn't have to be checked, and can't
turn into the sort of mess that ECN did).  From a practical
standpoint, I don't think it's worth delaying DNSSEC deployment just
for this change, which is why I haven't made noise about it.

---

From: Dan Massey <[email-masked]>
Date: Mon, 05 Aug 2002 14:16:44 -0400

> for this change, which is why I haven't made noise about it.

This is a good point.  In the restrict key form, the KEY record has a
protocol octet that must be 3.  In addition, there are 2 flag octets where
only bit 7 is used.   This is a somewhat odd structure at best.and
someone starting from scratch would clearly not do this.

But it accomplishes the objective with minimal changes and without
creating any compatability problems for existing zone keys.  In my view,
the practical issues of making minimal compatible changes and not futher
delaying DNSSEC trumps the desire to further optimize structure.

Dan

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Aug 2002 14:40:27 -0400

>regardless of the truth of your arguments.

I would think that a better approach would be to document what 
determines whether a design of a resource record is "good" or "bad." 
The document would not need to be a tutorial to RR proposers as much 
as it would be a resource for DNS reviewers to say "I don't like this 
RR because of what's in section x.y."

A well designed solution to an application key in DNS would have to:
     1) Solve the problem facing the application
     2) Do so in a way that is in accordance with appropriate security practices
     3) Be copacetic with DNS

As the DNS community is just one leg of this, I would think that the 
best we could hope for is defining what is copacetic.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 05 Aug 2002 18:56:17 +0000

> RR because of what's in section x.y."

that sounds like a great resource.  but it's not going to help "us" reach
consensus on key-restrict, even if it were finished (including all the
inevitable arguments about the validity of proposed section x.y) TODAY.

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.

---

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: [email-masked]
Date: Tue, 06 Aug 2002 08:09:38 +1000

> KEY/SIG/NXT is for IN only.

	No.  KEY/SIG/NXT are for securing the DNS *independent* of
	class.

	You missed the entire point of the statement I made.

	If you exhaust the type space in IN then you have additional
	classes that you can use.
 
> Also, NXT doesn't provide authenticated denial across IN boundaries.

	This makes no sense.

	Mark

---

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 12:53:03 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Rob" == Rob Austein <[email-masked]> writes:
    Rob> There is a specific problem with using the KEY RR type for things
    Rob> other than DNSSEC's own internal keying.   It's called the "sub-typing
    Rob> problem" and has been discussed namedroppers many times before, please
    Rob> check the archives if you don't already understand the problem.

  We know that it can be solved by one of two means:
     1) well known naming scheme that lets me ask for just what I want.
     2) creating a RR for each use.

  There are various schemes for making the name of #1 be looked up
first. They are a total waste of time since they just add a needless layer of
indirection (I can't ask for just the NAPTR that I need, can I? I have to
sort through them), and they likely cost another round trip.

  Further, if we decide to designate a well known name for a particular key
usage, then there is little reason we can't use "KEY" RR as the format. 
  
    Rob> This is a totally separate discussion from whether putting keys for
    Rob> things other than DNSSEC itself into the DNS is a good or bad idea.
    Rob> If we stipulate that such keys should use a different RR type, I'm
    Rob> relatively agnostic on the subject.

  It is not for DNSSEC people to decide if DNSSEC provides the right trust
model for another protocol. It is for the designers of that protocol.

  That means that DNSSEC may not even provide the right trust model for
mapping of names to IP addresses for certain end-users!

  Any proposal that removes functionality without offering an immediate
alternative is a complete and total non-starter.  You later write:

  Rob> If the two halves of this proposal were at equal stages of readiness,
  Rob> this would be a reasonable way forward.  Unfortunately, they're not:

  Until such time as -restrict-key-for-dnssec is massively overhauled to 
remove the baseless FUD which occupies 90%, then I do not agree that removing
KEY has any documented justification.

---

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

-----BEGIN PGP SIGNED MESSAGE-----

  "we", being whom?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 Aug 2002 14:57:49 +0200

I have tried to summarize the needs OpenPGP data in DNS have, abstract
and URL to draft below.  Similar discussion also applies to S/MIME,
but I'm publishing the OpenPGP document now as it is developed as free
software and has more to gain from public debate.

It would be nice if this WG could decide which approach for
application keying material in DNS they would rather see, otherwise
every application is likely to design this separately.  The draft
below is one attempt to solve this separately, there is a draft for
IPSEC with another solution, and drafts for other application seems to
be in preparations.  Perhaps they can be reviewed and lead to a WG
recommendation. I've tried to raise this discussion a few times, but I
see little consensus or (in the words of Mr. Vixie) leadership in
solving this problem in a way that DNSEXT would prefer.  How do you
want it to be solved?

http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt

Abstract

   This draft describes the decisions made in one pair of applications
   [4][5] that respectively serves and retrieve OpenPGP [3] Certificates
   and Revocation Signatures using the CERT Resources Record [2].  The
   intent is to provide a discussion on the kind of general updates
   needed to the CERT specification, and some suggested specific updates
   for the OpenPGP sub-type.  It is offered in the hope that this
   specification, together with similar efforts for other applications,
   can be reviewed when designing a generic solution or guidelines for
   storing application keying material in the Domain Name System (DNS),
   should it ever happen.

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 Aug 2002 08:53:29 -0400

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "Rob Austein" <[email-masked]>
Sent: Sunday, August 04, 2002 12:53 PM
Subject: Re: [Design] Re: the KEY debate

>      2) creating a RR for each use.

Restricting KEY to DNSSEC only does solve the sub-typing problem - for
DNSSEC.  For everything else that wishes to use the DNS to store keys (IPSec
and SSH are the only 2 that come to mind).  APPKEY faced the same problem -
it just pushed the subtyping problem off to all the other protocols and left
DNSSEC as the lucky one.

Esoteric naming schemes (like SRV) bring an increased chance of admin error
(entering RR) and user error (queries).  A new RR for each application
wishing to use sounds better.  If it is good to restrict KEY to DNSSEC, then
having a separate RR type for any other public key is a good idea too.
Again - we get to avoid the sub-typing problem without resorting to other
tricks like naming schemes.

> model for another protocol. It is for the designers of that protocol.

I think Rob is referring to the ever-ongoing debate every time someone
suggests a new RR type be added to the DNS.  It's not a security debate,
more like a philosophy.  Some argue the DNS is fine to use to support other
protocols in this way, some consider it a bad thing.

I was in camp B.  Now I'm leaning towards camp A.  If some other protocol
thinks that using the DNS is the best way to distribute keys, or other
information, then a new RR might be in order.  I realize that we aren't the
best group to argue what the format of those new RR should be, and that
someone experienced with the protocol in question (IPSec, SSH, whatever)
needs to be included, but someone with DNS knowledge should be included as
well - to make sure it meshes with the agreed DNS spec.

> KEY has any documented justification.

Just because this draft restricts KEY to DNSSEC does not mean that there
will never be a way of storing other keys in the DNS.  Just that the DNS WGs
alone aren't the best people to do it.  There needs to be some input from
the designers of other protocols.  First question:  what special information
(besides the key itself) should be in a IPSec DNS RR RDATA?

Scott

---

From: John Schnizlein <[email-masked]>
Date: Tue, 06 Aug 2002 09:24:44 -0400

>http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt

Would you please explain how the recommendation below (from the above URL)
would accommodate "friendly e-mail addresses" of the form
[email-masked]?

My concern is that replacing the '@' with '.' in order to use a label format
would create a parsing problem for FirstName.LastName.host.example. There
could be mailbox for FirstName on a host with the name LastName.host.example.

      ... However, it is recommended by PGP that such names include
      the RFC 822 email address of the party, as in "Leslie Example
      <[email-masked]>".  If such a format is used, the CERT should be
      under the standard translation of the email address into a domain
      name, which would be leslie.host.example in this case.  If no RFC 822
      name can be extracted from the string name no specific domain name is
      recommended.

John

---

From: Derek Atkins <[email-masked]>
Date: 06 Aug 2002 09:42:12 -0400

Michael,

Remember that the IETF is based on rough consensus, and there has been
rough consensus within the DNSEXT working group to restrict "KEY" to
only DNSSEC infrastructure.  Yes, you object.  We know that.  We
acknowledge that.  One objection does not invalidate a rough
concensus.

May I make a suggestion: instead of using your energy to write long
missives about how restrict-key sucks, may I suggest that instead you
refocus that time and energy to write a draft that defines a new FSKEY
record that defines how to store FreeS/WAN keys in DNS?  Feel free to
copy-and-paste the text out of 2535 that defines the KEY record, if
you feel that is sufficient (I would not actually recommend that -- I
don't think you need or want the subtyping in the 2535 KEY record).

My recollection of reading the OE draft was that you needed additional
information above and beyond what was provided by the KEY record.  In
particular, IIRC, you needed a pointer to the gateway and the network
size to use.  This would be the perfect opportunity to combine this
all into a single record!

I am very sure that if you write such a draft it can progress
extremely quickly through the process.

-derek

-- 
       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: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 20:47:04 +0700

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

  | or even a series of different RR's, on a per-security-system basis.

If this stuff has to be in the DNS at all, rather than accessed via some
better constructed protocol for the purpose, then that would be the way
to accomplish it.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 20:56:22 +0700

Date:        Tue, 06 Aug 2002 09:24:44 -0400
    From:        John Schnizlein <[email-masked]>
    Message-ID:  <[email-masked]>

  | Would you please explain how the recommendation below (from the above URL)
  | would accommodate "friendly e-mail addresses" of the form
  | [email-masked]?

The same as is done in the SOA.rname field, one would presume.

That is, as FirstName\.LastName.host.example.

kre

ps: this message should not be taking as expressing an opinion on the
draft in question.

---

From: Derek Atkins <[email-masked]>
Date: 06 Aug 2002 10:00:59 -0400

Paul,

Would you be willing to commit "BIND development resources" to
implement all these various foo-key records?

-derek

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 10:03:06 -0400

I've not read the draft, but seen this issue come up before (e.g., 
the MNAME in the SOA).  FirstName\.LastName.host.example -> 
[email-masked].

See the note at the bottom of page 36 of RFC 1035.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 10:15:49 -0400

At 2:57 PM +0200 8/6/02, Simon Josefsson wrote:
>every application is likely to design this separately.

I think it would be preferable for applications to design solutions 
to their problems, at least at first.  If enough applications have 
designed "experimental" solutions, perhaps then we (DNSers) can 
extract a systematic solution.  Without proper input from the 
applications, expecting DNSers to design a better approach is 
unrealistic.

>solving this problem in a way that DNSEXT would prefer.  How do you

I understand your rationale for wanting the DNS community to solve 
this problem to stave off bad solutions from the applications.  But I 
think this is a siren's call.  I doubt that a good-for-DNS solution 
designed by the DNS community will also be 
good-for-(all-)applications, just as much as you doubt that a 
good-for-(each-)application solution will also be good-for-DNS.  I 
prefer the former though for a number of previously detailed reasons.

I really do want to see documents come from the applications that are 
interested in distributing keying material via DNS.  This is 
happening, there's a proto-draft for the SSH application in 
preparation.  I was disappointed that there was no IPsec OE input to 
the SIKED BoF, even though there was a draft available then.  I have 
the OpenPGP draft printed on my desk for reading next.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 10:21:16 -0400

>implement all these various foo-key records?

I would expect that we'd do what we used to do...rely on contributed code ;)

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 22:16:06 +0700

Date:        06 Aug 2002 10:00:59 -0400
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | Would you be willing to commit "BIND development resources" to
  | implement all these various foo-key records?

I'm not Paul (nor Ed) but if all of these records have the same syntax,
which is what would be required for the magic name variant to work, then
the resources needed to support 10 or 20 of the things is essentially
the same as those required to support one (just a few extra labels in a
couple of case statements for the extra types with the same syntax).

On the other hand, if they need to differ, then the magic name scheme doesn't
work at all, so there's no choice.

kre

---

From: Paul Vixie <[email-masked]>
Date: Tue, 06 Aug 2002 16:21:22 +0000

> >Would [ISC] be willing to commit "BIND development resources" to

of course.  our charter, from www.isc.org, is

	... developing and maintaining production quality Open Source
	reference implementations of core Internet protocols.

> I would expect that we'd do what we used to do...rely on contributed code ;)

that's been truer in the past than in the present.  we don't "rely" as much
on contributed code as we once did.  however, please note that contributions
of code and equipment (and money) are always welcomed.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 13:15:09 -0400

>http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt

Issue #1 -> going from a digital signature to finding a copy of a 
certificate needed to verify the signature.  Sigh, always an issue.

This is a problem I've had experience with in the X.509 realm.  In my 
lab-baked solution, I just included a domain name with the signature 
in the data structures I passed.  I can understand how this might be 
different when trying to weld this into existing applications, like 
email.

Defining a convention for determining a domain name from a signature 
structure is one thing being done in this draft.  Not being a PGP 
expert, I can't comment or really add to the text.  One concern about 
section 2.1 is to make sure that the added bytes don't scrunch up the 
name (a concern I read in Eric Hall's expired draft on DNS data 
considerations).  A concern in section 2.2 is that relying on a CNAME 
at one name to point to another limits what can be stored at the 
owner of the CNAME.  Hopefully no other application wants to have 
data at such a name.  (These are examples of why specifying naming 
conventions can be tricky.)

The rest of the issues I've broken down section-by-section:

Section 3 is a perfect example of why applications need to do this 
work and not DNS.  (See how "we"[0] screwed up the first time?  You 
want to ask us to do this again?)  The same issue happened with SSH 
and is what prompted APPKEY.  For SSH the KEY RR was insufficient 
because the KEY RR couldn't convey the SSH version information needed 
to decipher the key.  Apparently, "PGP" isn't specific enough for the 
CERT RR.  (Maybe just more algorithm types are needed.)

Section 4 is an unforeseen problem for DNS - data too big for an RR, 
and perhaps even an RR set.  I don't know if you want to suffix names 
though, it separates data, but then again if you are worried about 
message size you want it separated.  I would argue that at this 
point, just use SRV records and make queries into a system more 
suited to large data elements.

Section 5 twists the key id field, and I don't know that you want to 
go there.  This makes the interpretation of that field (which is 
supposed to hold the key id of a KEY RR held at the same name, a 
useless appendage pending restrict-KEY) dependent on the algorithm 
field, unless we redefine that field altogether, given restrict key.

Section 6 talks about revocation, and I'm not sure I know enough PGP 
to know about this.  In X.509, I was able to store both DER-encoded 
certificates and revocation lists in the PKIX algorithm type.

One thing that helped X509 certificates in DNS.  Once I managed to 
locate the initial certificate, it had the domain names of all others 
I needed - the "AltName" of the issuer and also of the revocation 
list.  So once I entered DNS, I could bounce through the system 
easily and without neededing a name conversion convention.  I was 
even able to specify multiple domains as AltNames too.

[0] No offense intended to the editors, they were working at the 
beck-and-call of the WG.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 14:39:34 -0400

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

?

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

>   I see these as efforts to derail DNSSEC deployment.

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

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

---

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

> different when trying to weld this into existing applications, like

OpenPGP signatures contains the Key ID of the signer, so assuming the
recipient has configured her client to look into
e.g. dnskeys.josefsson.org, this isn't a problem.

When OpenPGP is used in e-mail the sender's email address ("From:")
can be used as a hint to find the OpenPGP certificate if the recipient
simply enable DNS-based key servers, no need to specify a particular
zone to look into.

> expert, I can't comment or really add to the text.

Actually, this is under discussion, and the text in the draft will be
modified and enhanced with a rationale for the owner name
recommendation.

> One concern about section 2.1 is to make sure that the added bytes
> don't scrunch up the name (a concern I read in Eric Hall's expired
> draft on DNS data considerations).  A concern in section 2.2 is that
> relying on a CNAME at one name to point to another limits what can
> be stored at the owner of the CNAME.  Hopefully no other application
> wants to have data at such a name.  (These are examples of why
> specifying naming conventions can be tricky.)

KeyId based owner names will be used in "special" zones.  The zone
name is either configured by the recipient, or specified in the
OpenPGP preferred key server sub-packet.  So I don't expect this to be
a problem.  It would for a generic solution though.

> CERT RR.  (Maybe just more algorithm types are needed.)

The "problem" here, as I perceive it, is that the CERT specification
tried to be specific about RDATA but failed.  If it simply defined the
framework, it could leave the description of individual sub-types to
other documents.  Defining the framework is what I'd like this WG to
do.  This also splits the design of the DNS part to DNS WGs and design
of application-specific data parts to other people.

> message size you want it separated.

How would it be solved otherwise?

> I would argue that at this point, just use SRV records and make
> queries into a system more suited to large data elements.

This may lead to security problems.  If I store the data in DNS, I can
use DNSSEC or TSIG to protect the data, if I use SRV I can only
protect the pointer to the server, but the connection to that server
is not protected.

> field, unless we redefine that field altogether, given restrict key.

The Key Id field of CERT is computed on the key inside the
certificate.  It has nothing to do with the KEY RR, except the
algorithm numbers are shared.  I don't see how this "twists" the
field, from how I read the definition in RFC 2538 it looks like I'm
using it for exactly what it was intended for -- optimizing cert
selection when there are several keys/certs.

> certificates and revocation lists in the PKIX algorithm type.

Problem is that revocation data is small, so I want to separate it
from certificate data so packets aren't overflowed.  Sub-typing can't
do that though, but it was suggested to use different owner names to
solve that.

> list.  So once I entered DNS, I could bounce through the system easily
> and without neededing a name conversion convention.  I was even able
> to specify multiple domains as AltNames too.

OpenPGP has something similar, although it is not always used.  Just
as X.509, that is.

---

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

> don't think you need or want the subtyping in the 2535 KEY record).

Is this the WG blessed answer to storing application keying material
in DNS?  Defining new RRs, that is.  If it isn't the WG blessed
solution, why should he follow this suggestion instead of continuing
to use what is already implemented and described in a draft?  It seems
like someone else could suggest FreeS/WAN to sub-type CERT instead, or
sub-type KEY (which actually was designed for this purpose once upon a
time), or encode the key into AAAA records, and these recommendations
would be equally valid and equally useful to someone that has already
implemented and documented another solution.

Having a blessed (as in reviewed and designed by DNS people) answer to
this problem was all that SIKED was about, at least that's my
interpretation of it.

---

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

Edward Lewis <[email-masked]> writes:

> I think it would be preferable for applications to design solutions to
> their problems, at least at first.  If enough applications have

Yes.  That's why I wrote the draft.  I used to believe that this
problem was easy enough so that a framework could be developed by the
DNS community for application developers, but I now realized this
isn't happening.  So I'll solve the problems as an application writer
and document it and leave it at that.

---

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

Edward Lewis <[email-masked]> writes:

> all.  

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Aug 2002 16:59:11 -0400

At 10:29 PM +0200 8/6/02, Simon Josefsson wrote:
>in DNS?  Defining new RRs, that is.

Seems like the best current approach to me, but there's no "blessed" 
label to apply to it.

>this problem was all that SIKED was about, at least that's my

Oh my lord no!  SIKED was accidently about DNS folks defining how to 
put application keys into DNS - only 'cause we started it.  SIKED 
wasn't supposed to be so - which is why it was forked off from 
DNSEXT.  But we kept coming back to DNS and that's why there's no 
SIKED II BoF.  Had SIKED went anywhere, we would have been in the 
Security Area, not in the areas currently doing DNS (Internet and 
O&M).

Look back at the keydist archives.  I tried floating discussion 
topics, at first trying to define the problem and then later "Let's 
assume DNS is involved."

http://www.cafax.se/keydist/maillist/2001-12/msg00009.html
and
http://www.cafax.se/keydist/maillist/2002-03/msg00005.html
and
http://www.cafax.se/keydist/maillist/2002-03/msg00048.html

---

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

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

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

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

---

From: Derek Atkins <[email-masked]>
Date: 06 Aug 2002 17:24:57 -0400

> implemented and documented another solution.

No, it is not the WG blessed answer.  It is a suggestion, and was
framed as such.  You are correct that subtyping CERT is another
reasonable approach.  I do not believe that subtyping KEY is a
reasonable approach (although a copy-and-paste of the text defining
KEY into a new draft that defines fooKEY would be reasonable, IMHO).

At this point I am just tired of the running around the issue.  I give
up.  I want to see progress.  As I was a vocal proponent of
sub-typing, I give up and buy into the type-per-application and have
encouranged Mr. Richardson to work towards that goal.

If this means I need to host a DNSKEY BOF in Atlanta, so be it.

> this problem was all that SIKED was about, at least that's my

No, SIKED was trying to be more.  I want to see a specific niche
carved out: a framework for how to store application keys in DNS for
those applications that completely understand all the issues involved.
My hope would be that we could create a template that applications
could follow to define their own key-type.  Most of the work would be
writing the security considerations to appease people like Mr. Moore
who clearly believes that nobody should trust application keys from
DNS, whereas there is clearly a community who believes that
DNSSEC-based security is "good enough."

So please, Mr. Richardson, write that draft.  I look forward to
reading it.  Perhaps it can be the basis of this "template" (if said
pipe-dream of mine ever happens).

-derek

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 6 Aug 2002 23:40:06 +0200 (CEST)

On Tue, 6 Aug 2002, Simon Josefsson wrote:

> Is this the WG blessed answer to storing application keying material in
> DNS?  Defining new RRs, that is.

I suggest that the people who believe they have a protocol that would
benefit from storing keying material in the DNS define an RRs, write some
code and deploy it - then we'll evaluate and see what does work and what
does not. the alternative might of course be to discuss this forever and
while we're discussing people will go off using TXT records instead.

	jakob

ps. I know OE currently uses TXT records and there is a reason for it
    since there currently isn't anything better - let's build that better
    thing.

---

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

>update, it clearly derails DNSSEC deployment.

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

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

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

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

         Olafur

---

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

-----BEGIN PGP SIGNED MESSAGE-----

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

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

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

---

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

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

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 7 Aug 2002 09:20:59 -0400

----- Original Message -----
From: "Derek Atkins" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Michael Richardson" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Rob Austein"
<[email-masked]>
Sent: Tuesday, August 06, 2002 5:24 PM
Subject: Re: [Design] Re: the KEY debate

> DNSSEC-based security is "good enough."

I've been thinking the same thing - a BOF about using DNS to support other
applications and set up a general framework/process for getting any type of
network information in the DNS.  Not just keys.  The hard part would be to
stress that the DNS isn't an end all solution, but a possible option for
things like certificates and key distribution, now that DNSSEC has added
integrity and source authentication.

I always thought SIKED was more of a general purpose "Interent Key
Distribution methods" BOF.  The fact that "DNS people" started it was
supposed to be irrelavent, but I think that may have been one of the caused
it didn't catch on:   Other people thought it was strickly a DNS group when
it was hoped to be more.  Correct me if I'm wrong.

<joke>
As for the BOF, why don't we all call it PDNS, for "Pimping DNS for other
applications"?
Depends on how you view it I guess.
</joke>

Scott

---

From: bert hubert <[email-masked]>
Date: Wed, 7 Aug 2002 15:52:52 +0200

> Depends on how you view it I guess.

Well, our daemon is already called 'pdns' so please don't :-)

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

---

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

on 8/7/2002 8:20 AM Scott Rose wrote:

> I've been thinking the same thing - a BOF about using DNS to support
> other applications and set up a general framework/process for getting
> any type of network information in the DNS.

Ugh. The more crap we put into DNS the less useful it will be for
lightweight lookups. We'll need another DNS if we pimp this one.

Might I suggest that it would be more fruitful to work on ways to support
applications in one or more external services, and solving the problems
with those services such that they would be usable. I am working on the
LDAP-WHOIS stuff just for this purpose (give every delegated domain and
netblock LDAP referral hooks at the time of delegation). There are lots of
other options out there that also deserve attention.

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

---

From: David Conrad <[email-masked]>
Date: Wed, 07 Aug 2002 12:56:35 -0700

> lightweight lookups. We'll need another DNS if we pimp this one.

Can we _PLEASE_ stop with this FUD?

Explain exactly why adding a new RR type, one that does not change the
underlying DNS algorithms, will have any significant impact on the DNS, much
less make it "less useful".  On the contrary, it would make the DNS more
useful, pretty much by definition.

Rgds,
-drc

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 7 Aug 2002 22:00:47 +0200 (CEST)

> lightweight lookups. We'll need another DNS if we pimp this one.

why would more data (aka crap) in the dns render it less useful for
lightweight lookups?

> Might I suggest that it would be more fruitful to work on ways to
> support applications in one or more external services, and solving the
> problems with those services such that they would be usable. I am
> working on the LDAP-WHOIS stuff just for this purpose (give every
> delegated domain and netblock LDAP referral hooks at the time of
> delegation). There are lots of other options out there that also deserve
> attention.

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.

	jakob

---

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

> underlying DNS algorithms, will have any significant impact on the DNS,
> much less make it "less useful".  On the contrary, it would make the
> DNS more useful, pretty much by definition.

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. Less useful.
Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful.

Cache overflow is already common in large ISPs. Less useful.

---

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

> properties you've suddenly almost built that other DNS and called it LDAP

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.

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 16:31:15 -0400

> lightweight lookups. We'll need another DNS if we pimp this one.

HUH?  I don't see where this leap in logic comes from.  Just
because I can make a query for:

        myserver.host.example. IN SSHKEY

does not imply that lookups for

        myserver.host.example. IN A

are any "heavier".  So, either you have a specific example in mind
which you did not state, or you are just spreading FUD on the topic.
I don't know which, but I'd appreciate it if you actually stated facts
instead of unsubstantiated non-problems.

-derek

---

From: "Jason Coombs" <[email-masked]>
Date: Wed, 7 Aug 2002 10:55:02 -1000

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

When security evaporates suddenly due to bugs in DNSSEC deployments (bad
software) or in the unlikely event of a flaw in the protocol extensions to
DNS to enable DNSSEC, the damage is great instead of relatively small.
Consider the following real-world example of security evaporating suddenly
(RIGHT NOW!) with respect to SSL due to a bug in the way that Internet
Explorer processes (and trusts) certificate chains. And think about the
damage that would be done if something similar happens to DNSSEC with
APPKEYs (very, very bad, many applications left unsecured suddenly and
automatically) compared to the damage that would be done without APPKEYs
(revert to classic DNS security, effectively, but applications still have
their own independent mechanisms for establishing trustworthiness of the
work they do while bad DNSSEC software is patched and no DNSSEC lookups can
be trusted -- just as no SSL connections made using Internet Explorer RIGHT
NOW should be trusted: see below).

========================================================================
Internet Explorer SSL Vulnerability 08/05/02
Mike Benham <[email-masked]>
http://www.thoughtcrime.org

========================================================================
Abstract

Internet Explorer's implementation of SSL contains a vulnerability that
allows for an active, undetected, man in the middle attack.  No dialogs
are shown, no warnings are given.

========================================================================
Description

In the normal case, the administrator of a web site might wish to provide
secure communication via SSL.  To do so, the administrator generates a
certificate and has it signed by a Certificate Authority.  The generated
certificate should list the URL of the secure web site in the Common Name
field of the Distinguished Name section.

The CA verifies that the administrator legitimately owns the URL in the CN
field, signs the certificate, and gives it back.  Assuming the
administrator is trying to secure www.thoughtcrime.org, we now have the
following certificate structure:

[CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

When a web browser receives this, it should verify that the CN field
matches the domain it just connected to, and that it's signed using a
known CA certificate.  No man in the middle attack is possible because it
should not be possible to substitute a certificate with a valid CN and a
valid signature.

However, there is a slightly more complicated scenario.  Sometimes it is
convenient to delegate signing authority to more localized authorities.
In this case, the administrator of www.thoughtcrime.org would get a chain
of certificates from the localized authority:

[Issuer: VeriSign / Subject: VeriSign]
-> [Issuer: VeriSign / Subject: Intermediate CA]
   -> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org]

When a web browser receives this, it should verify that the CN field of
the leaf certificate matches the domain it just connected to, that it's
signed by the intermediate CA, and that the intermediate CA is signed by a
known CA certificate.  Finally, the web browser should also check that all
intermediate certificates have valid CA Basic Constraints.

You guessed it, Internet Explorer does not check the Basic Constraints.

==========================================================================
Exploit

So what does this mean?  This means that as far as IE is concerned, anyone
with a valid CA-signed certificate for ANY domain can generate a valid
CA-signed certificate for ANY OTHER domain.

As the unscrupulous administrator of www.thoughtcrime.org, I can generate
a valid certificate and request a signature from VeriSign:

[CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]

Then I generate a certificate for any domain I want, and sign it using my
run-of-the-mill joe-blow CA-signed certificate:

[CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org]
   -> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com]

Since IE doesn't check the Basic Constraints on the www.thoughtcrime.org
certificate, it accepts this certificate chain as valid for
www.amazon.com.

Anyone with any CA-signed certificate (and the corresponding private
key) can spoof anyone else.

========================================================================
Severity

I would consider this to be incredibly severe.  Any of the standard
connection hijacking techniques can be combined with this vulnerability
to produce a successful man in the middle attack.  Since all you need is
one constant CA-signed certificate (and the corresponding private key), an
attacker can use that to generate spoofed certificates for other domains
as connections are intercepted (on the fly).  Since no warnings are given
and no dialogs are shown, the attacker has effectively circumvented all
security that an SSL certificate provides.

There is some level of accountability, though, since a user who randomly
chooses to view the certificate of the web site she's visiting will see
the attacker's certificate in the chain.  However, by that point the
damage has already been done.  All "secure" data has already been
transmitted.

=========================================================================
Affected Browsers

Netscape 4.x and Mozilla are NOT vulnerable.

IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable.

When VeriSign issues certificates, usually they leave out the CA Basic
Constraint information all together.  Thawte tends to explicitly put in a
Basic Constraint CA = FALSE with the critical bit set to TRUE.

When the CA Basic Constraint on the middle certificate is explicitly set
to false and marked as critical, IE 6 does not follow the chain.  When
it's not mentioned at all, IE 6 follows the chain and is vulnerable.

This just means that an attacker needs to use a VeriSign-issued
certificate to exploit IE 6.

=========================================================================
Working Exploit

I've set up a URL to demonstrate this problem.  If you want to test
browsers not listed above or need proof of this vulnerability, contact me
and I'll give you the information.

=========================================================================
Vendor Notification Status

Last week I saw Microsoft downplay and obfuscate the severity of the
IE vulnerability that Adam Megacz reported.  After seeing that, I don't
feel like wasting time with the Microsoft PR department.

- Mike

--
http://www.thoughtcrime.org

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Conrad
Sent: Wednesday, August 07, 2002 9:57 AM
To: Eric A. Hall; Scott Rose
Cc: namedroppers
Subject: Re: [Design] Re: the KEY debate

Rgds,
-drc

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 16:47:13 -0400

> UDP queries for qtype ALL. Adding "just one more" RR to a set means that

Luckily "qtype all" is generally only performed in debugging
situations and not by the majority of applications out there.
Can you give examples of applications that actually make queries
for qtype all?

> all first-pass queries for an overloaded owner name fail. Less useful.

HUH?  What do you mean "all first-pass queries?"  My SSH application
makes a query for "host.example. IN A".  What are YOU talking about?

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

I'd be very surprised if you exceed a 64KB response!  You'd need to
add a LOT of 4k RRs to reach this size.  Also, that still presupposes
'qtype any' which is NOT what most application should be using
anyways.

> Cache overflow is already common in large ISPs. Less useful.

"cache overflow"?  What _ARE_ you talking about?

-derek

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 16:52:49 -0400

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

---

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

>Can you give examples of applications that actually make queries

dig -x does (or used to).

Perhaps also a debugging tool, but this is trivia I've carried for 
years and have been waiting to use it someday. ;)

---

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

-derek

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 17:26:49 -0400

> with arbitrary dynamically-discovered third parties, so your examples don't

I don't know your background, but it sounds like you're viewing SSH as
a telnet replacement, and IPsec as a VPN solution.  Unfortunately
you'd be wrong on both accounts.

I want 100% of my communications encrypted.  If I go and ping a host,
I want that encrypted.  If I finger, I want that encrypted.  If I ftp,
http, smtp, ntp, or anything else, I want that encrypted.

IPsec is the tool I'd like to use (because SSH is subject to the
TCP-RST attack).  I'd like IPsec to happen and start encrypting
traffic with EVERY HOST I contact, regardless of why I contact them,
or how.

Note that encryption != authentication/authorization.  If you want to
use SSH or IPsec for authentication/authorization, then you DEFINITELY
want to be able to verify the key.  However:

        1) I am not proposing that, and
        2) In many cases, a DNSSec-provided key can be "good enough" for
           limited authentication/authorization.

> the area of common sense.

So I need to contact this random site out there -- I heard about it
through a friend of a friend.  I want my traffic encrypted.  How do I
get their key?  I now need to dynamically discover this key across
domains.  Why?  Because I want ubiquitous, end-to-end encryption of
all traffic.  I could just use ephemeral diffie-helman, but that's
vulnerable to a man-in-the-middle.  if I had some other key that I
could grab, even if it wasn't 100% guaranteed, I've now increased my
protection against the MitM.

Note that I want "good enough" security, not "protect me from the NSA"
security.  In this case, IPsec opportunistic encrypting using keys in
DNS would solve my problem.  This would give me my encryption, which
is all I want.

If you still do not understand this problem space I'd be more than
happy to talk to you offline -- we don't need to waste the list's
bandwidth on your education.

-derek

---

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

on 8/7/2002 3:31 PM Derek Atkins wrote:

> HUH?  I don't see where this leap in logic comes from.  Just because I
> can make a query for:
>
> are any "heavier".

Of course they aren't. It is the queries for myserver.host.example. with
qtype=ALL that are heavier.

And to answer your next question, sendmail and qmail both use qtype=all
out of the box.

And to give you an example:

  Z:\>dig @ns1.hotmail.com. hotmail.com. any

  ; <<>> DiG 8.3 <<>> @ns1.hotmail.com. hotmail.com. any
  ; (1 server found)
  ;; res options: init recurs defnam dnsrch
  ;; got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 24, AUTHORITY: 4, ADDITIONAL: 18
  ;; QUERY SECTION:
  ;;      hotmail.com, type = ANY, class = IN

  ;; ANSWER SECTION:
  hotmail.com.            1H IN A         64.4.52.7
  hotmail.com.            1H IN A         64.4.53.7
  hotmail.com.            1H IN A         64.4.43.7
  hotmail.com.            1H IN A         64.4.44.7
  hotmail.com.            1H IN A         64.4.45.7
  hotmail.com.            1H IN MX        5 mx01.hotmail.com.
  hotmail.com.            1H IN MX        5 mx02.hotmail.com.
  hotmail.com.            1H IN MX        5 mx04.hotmail.com.
  hotmail.com.            1H IN MX        5 mx05.hotmail.com.
  hotmail.com.            1H IN MX        5 mx06.hotmail.com.
  hotmail.com.            1H IN MX        5 mx07.hotmail.com.
  hotmail.com.            1H IN MX        5 mx08.hotmail.com.
  hotmail.com.            1H IN MX        5 mx09.hotmail.com.
  hotmail.com.            1H IN MX        5 mx10.hotmail.com.
  hotmail.com.            1H IN MX        5 mx11.hotmail.com.
  hotmail.com.            1H IN MX        5 mx12.hotmail.com.
  hotmail.com.            1H IN MX        5 mx13.hotmail.com.
  hotmail.com.            1H IN MX        5 mx14.hotmail.com.
  hotmail.com.            1H IN MX        5 mx15.hotmail.com.
  hotmail.com.            1H IN NS        ns1.hotmail.com.
  hotmail.com.            1H IN NS        ns2.hotmail.com.
  hotmail.com.            1H IN NS        ns3.hotmail.com.
  hotmail.com.            1H IN NS        ns4.hotmail.com.
  hotmail.com.            1H IN SOA       ns1.jsnet.com. dns.hotmail.com.
  (
                                        2002080603      ; serial
                                        8H              ; refresh
                                        1H              ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

  ;; AUTHORITY SECTION:
  hotmail.com.            1H IN NS        ns1.hotmail.com.
  hotmail.com.            1H IN NS        ns2.hotmail.com.
  hotmail.com.            1H IN NS        ns3.hotmail.com.
  hotmail.com.            1H IN NS        ns4.hotmail.com.

  ;; ADDITIONAL SECTION:
  mx01.hotmail.com.       1H IN A         65.54.254.145
  mx02.hotmail.com.       1H IN A         65.54.254.145
  mx04.hotmail.com.       1H IN A         65.54.254.145
  mx05.hotmail.com.       1H IN A         65.54.254.129
  mx06.hotmail.com.       1H IN A         65.54.254.129
  mx07.hotmail.com.       1H IN A         65.54.254.129
  mx08.hotmail.com.       1H IN A         64.4.49.7
  mx09.hotmail.com.       1H IN A         64.4.49.71
  mx10.hotmail.com.       1H IN A         64.4.49.135
  mx11.hotmail.com.       1H IN A         64.4.49.199
  mx12.hotmail.com.       1H IN A         64.4.50.7
  mx13.hotmail.com.       1H IN A         64.4.50.71
  mx14.hotmail.com.       1H IN A         65.54.232.7
  mx15.hotmail.com.       1H IN A         65.54.232.71
  ns1.hotmail.com.        1H IN A         216.200.206.140
  ns2.hotmail.com.        1H IN A         216.200.206.139
  ns3.hotmail.com.        1H IN A         209.185.130.68
  ns4.hotmail.com.        1H IN A         64.4.29.24

  ;; Total query time: 1000 msec
  ;; FROM: ferret to SERVER: ns1.hotmail.com.  216.200.206.140
  ;; WHEN: Wed Aug 07 16:24:19 2002
  ;; MSG SIZE  sent: 29  rcvd: 869
                               ^^^

Just using A, MX, NS and SOA. All sendmail/qmail queries to hotmail.com
get restarted.

Sure, hotmail could improve this by publishing fewer A and MX RRs and
using some kind of load balancer. However, at that point they would have
left DNS for some other technology.

What is so hostile about my approach that warrants calling it FUD versus
the other abandonments (eg, load balancing) that are more common?

> So, either you have a specific example in mind which you did not state,
> or you are just spreading FUD on the topic. I don't know which, but I'd
> appreciate it if you actually stated facts instead of unsubstantiated
> non-problems.

I will gladly expound on my theories and ideas in detail if you wish.
Frankly, I didn't think that it would be necessary.

---

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

> just one, and that's bad.

No, sorry, this is just more FUD.   This is a problem that *any* key 
management daemon would have - it's got nothing to do with DNS per se.

---

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

> "cache overflow"?  What _ARE_ you talking about?

More data than will fit in memory, resulting in data being dropped.
Overloaded caches (being unable to actually make use of cached data) are
less useful.

---

From: Jim Reid <[email-masked]>
Date: Wed, 07 Aug 2002 14:46:00 -0700

>>>>> "Eric" == Eric A Hall <[email-masked]> writes:

    Eric> Well-know fact that excess RRs bound to an owner will cause
    Eric> overflow of UDP queries for qtype ALL.

This is a DNS administration issue rather than one about protocol
design. Adding more record types to an owner name just gives a longer
piece of rope to the less clueful. And they can already hang themselves
without introducing new record types. 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? It's not as if stupid and bad DNS
configurations are an unheard of phenomona today.

    Eric> Adding "just one more" RR to a set means that all first-pass
    Eric> queries for an overloaded owner name fail. Less useful.

Maybe. But probably not an issue if EDNS0 was widely deployed. And
anyway RFC3225 can be summarised as "use EDNS0 if you want to get
crypto gunk from a name server". Another one -- RFC3226 -- says "use
EDNS0 with certain UDP buffer sizes if you expect to get A6 and binary
labels (may they rest in peace) in the answer". Spot a trend here?

And let's not forget that caching will alleviate the impact of any
truncation. Sure, my server might get truncation when fetching signed
MX records for aol.com (say). But for one lookup per TTL interval to
aol.com's name servers. My mail systems will get truncation when they
repeat that query to my local cache, but that's no big deal: they
won't be beating up the aol.com name servers with those queries.

    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?

    Eric> Cache overflow is already common in large ISPs. Less useful.

I'm not sure I know what you mean by "cache overflow". Presumably it
is some condition that means truncated responses. If so, how much of
that would go away if EDNS0 was more widespread? If this is as much of
a problem today as you suggest, have you any numbers to support this
claim? Does anyone have name servers that are *really* suffering
because of truncated responses and TCP retries? And what percentage of
them have a genuine need to truncate responses as opposed to
truncating because of hostmaster silliness?

---

From: John Schnizlein <[email-masked]>
Date: Wed, 07 Aug 2002 17:43:23 -0400

>Can you give examples of applications that actually make queries

Would "qtype all" be the appropriate way for a DNS client to get
the RR-set so that it can check the validity of a signature?
Would "qtype all" be much more common when applications demand
assurance that the DNS reply is authentic?

Not taking sides, but the context of checking signatures should
be relevant.

John

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 17:51:07 -0400

> assurance that the DNS reply is authentic?

No.  A DNSSec-aware server is supposed to respond with the appropriate
SIG and NXT records on every query, so the client should not have to
query for qtype any.

> Not taking sides, but the context of checking signatures should

It is not.

-derek

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 17:43:01 -0400

> And to answer your next question, sendmail and qmail both use qtype=all

This sounds like a bug in those applications, not a bug in DNS.
I presume they are doing this to try to save a round trip?

> And to give you an example:
[snip]
>   ;; MSG SIZE  sent: 29  rcvd: 869

Yes, this is bigger than the 512 limit, but would still fit in a UDP
response.  EDNS0 solves this problem.  Turn on EDNS0 and you wont
restart your query.

> the other abandonments (eg, load balancing) that are more common?

It's not the abandonment proposal that is FUD, it's your statement
that "adding new record types breaks DNS".

-derek

---

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.

> 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:19:22 -0700

>>>>> "Eric" == Eric A Hall <[email-masked]> writes:

    Eric> My message was meant to suggest that we should be working on
    Eric> those alternatives so that there is somewhere else to put
    Eric> this stuff.

Well I fail to see how you can advance that position by making
non-sequiturs about TCP window and cache sizes.

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

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

And the point you are making here is.....? Apart from needing some
extra TCP headers, how would shifting more than 64k of data present a
problem? [BTW it's the window size that has a 16-bit value in TCP.
This has nothing to do with message size: a nebulous concept in a byte
stream protocol like TCP.] And anyway, doesn't the TCP window scale
option allow for *much* bigger windows than 64k?

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 18:21:13 -0400

"Eric A. Hall" <[email-masked]> writes:

> on 8/7/2002 4:43 PM Derek Atkins wrote:
> What I said is that adding more crap to DNS makes it less useful. I didn't
> say it would break DNS. That would be stupid.

My appologies for mis-paraphrasing you.

However I think many people here would disagree that it would be less
useful, and I believe that your stating so is still FUD.  First, I
don't think keys are crap.  Second, the only real issue are
applications that make T_ANY queries, and I maintain those
applications are broken (or mainly for debugging purposes, like dig).

So unless you are saying that DNS should not be used because sendmail
is broken, I think the statement that more data is less useful is FUD.

-derek

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 17:21:58 -0500

> non-sequiturs about TCP window and cache sizes.

Luckily for me, I'm not.

Kindly refer to section of 4.2.2 of RFC 1035.

---

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

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 18:23:55 -0400

> option allow for *much* bigger windows than 64k?

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

-derek

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 18:29:14 -0400

David Blacka <[email-masked]> writes:

> >>>>> "Derek" == Derek Atkins <[email-masked]> writes:
> 
>  Derek> "Eric A. Hall" <[email-masked]> writes:
> 
>  Derek> I'd be very surprised if you exceed a 64KB response!  You'd
>  Derek> need to add a LOT of 4k RRs to reach this size.  Also, that
>  Derek> still presupposes 'qtype any' which is NOT what most
>  Derek> application should be using anyways.
> 
> So... 16 is a LOT?

For one application?  Yes.

> Exceeding the 64k limit for a single message looks like might be
> another credible argument against sub-typing application keying data.
> I could easily imagine having 64k of CERT or APPKEY-like records at a
> given name at some point.

Indeed.. You'll notice that I have abandoned the single-RR-type
approach for the rrtype-per-app approach.

-derek

> -- 
> David Blacka    <[email-masked]> 
> Sr. Engineer    Verisign Applied Research

---

From: David Blacka <[email-masked]>
Date: Wed, 07 Aug 2002 18:27:04 -0400

So... 16 is a LOT?

---

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: Rob Austein <[email-masked]>
Date: Wed, 07 Aug 2002 18:48:15 -0400

> And to answer your next question, sendmail and qmail both use qtype=all

This was a bad idea in 1985, and has not improved with age.  It can
return the wrong answer under certain conditions, and the defence
against that failure mode involves at least as many queries as one
would have made if one just queried first for the MX then falling back
to querying for the A.

This is not hypothetical.  We tracked a series of whacky mail failures
at MIT-LCS in the early 1990s to another implementation of this same
bad idea (in a then-current version of MMDF).  We replaced the QTYPE=*
query with the obvious MX and A queries and the problems went away.

MMAILR never did this.  Postfix doesn't do this.  It's a misfeature.
Plow it under and sow its burial site with salt.  Don't defend it.

We now return you to your regularly scheduled interminable debate
about the true purpose of DNS.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 18:03:02 -0500

on 8/7/2002 5:21 PM Derek Atkins wrote:

> First, I don't think keys are crap.

Nor do I. I just wish there was somewhere else to put them.

> Second, the only real issue are 

That would be pretty dumb, too.

On the other hand, my bet is that more applications are likely to START
doing it once we have IPv6 applications that query for qtype=any instead
of doing AAAA before A.

---

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: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 18:05:34 -0500

> Nor do I. I just wish there was somewhere else to put them.

[...] along with the "other information" that "some other protocol
thinks that using the DNS is the best way to distribute" that Scott
mentioned in his message which spawned my retort.

---

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:12:58 -0400

>SIG and NXT records on every query, so the client should not have to

That's changed.  Only if the client asks for it.  My old site was 
blocked (months ago) by another because our early DNSSEC-signed zones 
were returning answers too big - we tripped an IDS.  So to be kind to 
old code, DNSSEC records are only returned when the client requests 
them.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:15:17 -0400

>TCP).  Perhaps EDNS1 can fix this (I don't know if EDNS0 does

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.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:04:18 -0400

>the area of common sense.

These questions have dogged me on this for quite a while, ever since 
our first effort to get SSH and DNS integrated (late 2000).  I rarely 
SSH to a host "for the first time" from across the Internet.

On the other hand, there are two reasons why you might not have the 
keys (etal) of the SSH host that you want to contact while you are on 
the road.  One is that the keys on the host may have been changed 
(local maintenance, emergency repair).  The other is that you may 
have just recompiled the kernel on your laptop, screwed it up, and 
had to reload from disk.  (Raise your hand if you have ever thought 
that the flight to the IETF would be a good time to "fix" your 
kernel.  Of course, if you are using security to carry out a truely 
critical function, you aren't likely going to rebuild your kernel.)

One aspect of the debate is not as much "how good" you want security, 
but is where on the sliding scale between "secure but brittle" and 
"loose and resilient."  Simplicity in security starts with having a 
restricted system and not letting it stray from the norm, like 
pinning down the routes to the roots.  Resilience in a system means 
that it will take any action necessary to reach the goal, even if 
unusual actions maybe needed, such as using alternate roads to travel 
around DC during rush hour.

If you desire resilience and security, you have to be prepared to do 
a lot of work.  Multiple certification chains are one start - 
although if you expect to use this, you open yourself to potentially 
eating up CPU cycles as part of a DOS attack.  You also had better be 
prepared to lose the use of your most expensive resource at any time 
(meaning you will have to budget at least 100% for overhead).

"It just goes to show you, it's always something." - I think this was 
Roseanne Roseanna Danna, a.k.a. Gilda Radner
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 8 Aug 2002 10:04:30 -0400

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
To: "John Schnizlein" <[email-masked]>; "Derek Atkins" <[email-masked]>
Cc: "namedroppers" <[email-masked]>
Sent: Thursday, August 08, 2002 9:10 AM
Subject: Re: [Design] Re: the KEY debate

> At 5:43 PM -0400 8/7/02, John Schnizlein wrote:
> Not really.  There's a different bit that a resolver uses to ask the
> server to return DNSSEC records.  In dig it is invoked with
> "+dnssec," in the protocol I forget whether it became a bit in the
> OPT record or not (DNSSEC OK bit)?
>

Correct.  The +dnssec flag in dig adds an OPT record with the DNSSEC OK bit
set.  That's the only way to get DNSSEC records added to a response.  Unless
you ask for them specifically (or ANY, I would guess - haven't actually
tried).

The OK bit is like an flag to the server to say "DNSSEC capabile resolver
asking the query"

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Aug 2002 09:10:02 -0400

The problem with asking QTYPE=All to get the signatures is that this 
may be answered by a version of a name servers (some old BINDs) that 
may not keep the SIG records and just the data.  Repeatedly asking 
for All to that server will not get the SIGs returned until the TTL 
ticks down to 0 for all records at the domain name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

> 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