To:
Jakob Schlyter <jakob@crt.se>
Cc:
Jaap Akkerhuis <jaap@bartok.sidn.nl>, Randy Bush <randy@psg.com>, <dnssec@cafax.se>
From:
Edward Lewis <lewis@tislabs.com>
Date:
Tue, 1 May 2001 12:03:04 -0400
Delivery-Date:
Wed May 2 08:48:02 2001
In-Reply-To:
<Pine.BSO.4.33.0105011124430.24513-100000@fonbella.crt.se>
Sender:
owner-dnssec@cafax.se
Subject:
Re: Keys at apex problem - New PUBKEY RR?
This thread has spread across two of my trips already! ;) If it keeps going till next week - that'll be three trips. I've been reading along, generally agreeing with what I've seen, even if the message was from Olafur. But I wanted to reply to the last few responses from Jakob (one to Patrik about "what's wrong with the KEY") and the one below. As far as the question about key, as Patrik discovered, according to the spec, there is no problem with KEY - until you get to the operational considerations listed by Jakob. This captures the essence of my original comment, which was a plea not to change KEY and just provide an option. Later messages on using the ownership name to differentiate keys makes me think even more that KEY shouldn't change and that there's no need for an alternate RR (APPKEY, PUBKEY). As far as Randy's "side" (as referenced below), my opinion is split, but I am decidedly not on Randy's side here. I groc (see & understand) Randy's point. A centralized infrastructure element, such as DNS, should be as simple and lightweight as possible for two reasons. It should never breakdown. It should never be a performance bottleneck (with breaking down an extreme case of this). A long time ago I came to these conclusions when researching middleware (long time ago = pre-1035). These long-held opinions of mine would lead me to agree with Randy - and I've already said I don't. Why? There isn't an option to DNS at this point. I don't see place applications can easily rely on to get meta-data. I am aware of LDAP, but haven't been convinced that it's the way to go for pulling keys. More importantly, I agree with Jakob that the use of DNS to hold keys is not a significant change from DNS without this service. At least if the method can avoid using DNS to be directory-like functions. Looking up an A record for host.example.fooco.com is isomorphic to looking up host._ssh._tcp.example.fooco.com's KEY set (assuming this is the convention for the SSH key I want...). So - even though my theoretical side sides with Randy, my operational side sides with Jakob. I think the operational issue is more important in this isolated case. (Note the qualification - isolated. Randy is looking at a broader context, prehaps making his side the "right" side.) At 5:33 AM -0400 5/1/01, Jakob Schlyter wrote: >On Mon, 30 Apr 2001, Jaap Akkerhuis wrote: > >> I have to side with Randy here. During this discussion I also >> noticed that peopl are mixin apple and oranges, as Randy eloquently >> state: >> >> o what we have is a generic problem, how to go securely from a secured >> lookup in the dns to a wide set of secure APPLICATIONS on hosts. > >but the questions is if whether we should use only DNS or have it >reference yet another lookup mechanism like LDAP. moving to LDAP over SSL >for looking up a relative small host key compared to using DNS and KEY is >not very lightweight and thus not fast nor simple (despite what the L in >LDAP says). it also doesn't scale as well as DNS. > >/Jakob > >-- >Jakob Schlyter <jakob@crt.se> Network Analyst >Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer.