Re: What are we trying to do?

[Greg Hudson <ghudson@MIT.EDU>]

On Mon, 2001-12-31 at 14:56, Randy Bush wrote:
> the apps folk have had two rrs added to the dns to supposedly meet their
> needs, srv and naptr.  if neither of these provides a way to form a safe
> security association, then one or both of them are broken and should be
> fixed.  what should not happen is adding more and more rrs (or overloading
> current ones) until they figure out how to get it right.

The NAPTR RFC has under security considerations:

   This document has discussed a way of locating a service, but has not
   discussed any detail of how the communication with that service takes
   place.  There are significant security considerations attached to the
   communication with a service.  Those considerations are outside the
   scope of this document, and must be addressed by the specifications
   for particular communication protocols.

It can hardly be said that the NAPTR RFC is "broken" for failing to do
something it ruled out of scope.  The SRV specification does not have
similar language, but it's clear that it, similarly, is not trying to
provide a secure association, merely a location.

If there were some established convention or rule that each area of the
IETF gets a very small quota of RR types, then I would agree that the
apps area never should have proposed both NAPTR or SRV, but instead
should have proposed a single RR type which does the job of both plus
security associations.  But I've certainly never heard of any such
convention; as such, blaming the apps area for not trying to solve this
problem in past RR specifications is pretty bizarre.

All that said, NAPTR is pretty flexible, and I'm sure there are ways we
could shoehorn a public key fingerprint in.  (I didn't particularly like
the way which was suggested here earlier, but there are other ways; for
instance, a new flag could be defined which signals the presence of a
key fingerprint.)  That would work nicely for ssh, for instance; you'd
get the server's public key the same way you do now, but you'd be able
to verify it using the NAPTR record in the DNS.  An attacker who can
subvert the DNS server would still have to conduct an active attack
against the ssh TCP connection to feed you the wrong key.