[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.



Home | Date list | Subject list