Re: Let's assume DNS is involved

[Simon Josefsson <simon+keydist@josefsson.org>]

"James Seng" <jseng@pobox.org.sg> writes:

> Continue the line of SSH, there are two side to this argument.
>
> The proponent argues that DNSSEC provides more effeciency for SSH and solve
> the problem of bootstrapping. The keys comes from the same source who
> provides the IP address. SSL session can be established with signed
> information from DNSSEC, without prior out-of-band exchange of keys.
>
> The opponent argues that we should not loading more stuff into the DNS,
> especially other existing technology can provide the same thing. LDAP
> servers can serves certificate as well as DNSSEC. Bootstrapping is not a
> problem since secure channel is not needed for certificate exchange.
> Locating the appropriate LDAP server is an undefined problem but that does
> not involved loading keys into the DNS.

My understanding is that SSH does not use certificates.  It uses raw
keys, which needs integrity protection.  So, if the machine is set up
to use DNSSEC, why not leverage this trust to deliver the raw keys
integrity protected as well?  Authentication of the key still need to
be done by the user, in the general case, but it is still a big
improvement to deliver SSH keys integrity protected.  A campus
environment can configure the SSH client to blindly trust SSH keys
delivered protected with their own DNSSEC zone key, if they want that.
This means that the DNSSEC zone key is used for authentication of data
as well. The end result is a big improvement, IMHO.

> Assuming I havent missed out anything, then all been equal, the question is
> whether the additional efficiency of using DNSSEC over LDAP is worth the
> effort/risk to load keys into the DNS.

No, storing the key in LDAP causes a bootstrapping problem that we
haven't solved.  Assuming DNSSEC takes off, that bootstrapping problem
is solved for DNS.  I think we have been over this point a few times..

> ps: something to think abt: what is the "problem" to add more stuff into
> DNS?

I wish people that used this argument would explain what the problem
is, I haven't seen any convincing argument so far.  The only argument
seem to be that it would increase the load on root servers or that it
would increase bandwidth to all DNS servers.  Noone has been able to
prove the first statement, and the second one is a poor argument.
Someone with limited bandwidth to their DNS server will simply not use
this stuff.  Neither will it use DNSSEC or anything else that also
increses bandwidth requirements.

>
> -James Seng
>
>> At 11:02 AM -0500 4/4/02, Stephen Farrell wrote:
>> >        What problem is being solved by DNSsec-based distribution
>> >        of signed keys that is not equally easily solved by use of
>> >        certificates ?  And why are certificates not an equally
>> >        good solution to that problem ?
>>
>> I think that this is a good (set of) central question(s).  I don't have a
>> ready answer to the question.  I agree that the "lack of a PKI" isn't an
>> answer, but I think that the lack is a symptom of the/an underlying
> problem.
>>
>> Earlier I felt that the reason why SSH (to pick on the topic locally
>> studied for some time) was a good candidate for keys in DNS was that
>> organizations run DNS and not CA's for their hosts.  Why network
>> administration has not picked up PKI as a core element is a good question
>> and shouldn't be an excuse to settle for the path of least resistence[1].
>>
>> [1] That being putting keys into DNS with the existing record types -
>> unless you consider the resistence put up by some critics. ;)
>>
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> Edward Lewis                                                NAI Labs
>> Phone: +1 443-259-2352                      Email: lewis@tislabs.com
>>
>> Opinions expressed are property of my evil twin, not my employer.
>>
>>
>>