Subject: RE: General comments on DNSSEC

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 17 Jun 2002 08:49:17 -0700

The current mandate for DNSSEC is 'too secure the Domain Name System'. That
is it. Given the difficulty the group has discussing the security and
operational issues of DNS it is not time to consider going beyond that
scope.

The DNSSEC spec essentially uses a certificate that is formed from a DNS
record, just as X.509 certificates were originally created by signing X.500
records. This is essentially a direct crib from the '78 Kohnfelder paper.

X.509v3 Certificates are not an appropriate mechanism to secure DNS for many
reasons, not the least of which being the relative complexity of the ASN.1
format used by X.509 certificates. While it may be the case that X.509 is no
more complex than ASN.1 everyone knows that if they tell a programmer to do
ASN.1 they are most likely to give notice while people beg to be allowed to
do XML projects.

X.509 certificates do not in general fit into an ethernet MTU so using
certificates would force DNS to use TCP. PGP Web of trust is not an
appropriate match to the DNS architecture, Pretty Good Privacy is not
designed to provide integrity of orgiin bound to a fixed hierarchical
namespace. Neither has a trust model that is a particularly good match to
DNS at this point. The PKIX model is now way more flexible than one would
want to deal with.

Using DNS records as certificates has several positives and some negatives.
The negatives are basically a consequence of trying to retrofit security
into a pre-existing directory (name) protocol. Sure you can do better than
DNSSEC if you decide to ditch backwards compatibility with DNS, only your
working group will never terminate and if by some miracle it did terminate
the product would never be used.

The objection to storing application keys in the DNS system itself has been
repeatedly stated. In general the party that manages the DNS system for an
enterprise does not have responsibility for managing users or applications.

It is impossible for a majority of large enterprises to use DNS as a general
directory for their users. DNS is not designed to support that use and as
Klensen and others have said for some time now we have to get out of
considering DNS as the first recourse for fixing every problem.

Clearly there is a need for a lookup mechanism for public keys that is bound
to the DNS system, so that for example one can lookup a key for
[email-masked] using the DNS system as the starting point.
Applications only want to have to deal with at most one such mechanism.

In the XKMS protocol we consider exactly this issue, how to discover the key
corresponding to [email-masked], starting from the DNS system.
Essentially we look up the SRV record for
_xkms_soap_http._tcp.alicecorp.test which directs us to an XKMS service
which supports the location service for the key we need.

Note that this process does not result in a trusted key, for that we have to
perform some form of validation (which may also be delegated to an XKMS
service but must be one we have an a-priori trust relationship with).

XKMS is currently being standardised in the W3C and has the support of all
the principal PKI vendors. The same physical machine could be used to host
XKMS and DNS servers but this is not required so a company with hosted DNS
could point their SRV record at their separately hosted XKMS service. The
separation also makes a lot of sense at the protocol level since the design
of the key management system does not need to consider the complexity of
DNS.

The killer app for DNSSEC is that it provides a means of authenticating the
DNS SRV record that directs queries to the relevant XKMS service. 

		Phill

--
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: "Andy W. Barclay" <[email-masked]>
Date: Mon, 17 Jun 2002 11:43:47 -0700

I fully agree with everything you say here, except for the
first paragraph.

According to the draft, draft-ietf-dnsext-dns-threats-01.txt,
the current mandate for DNSSEC is:
1) data integrity, and
2) data origin authentication.

"to secure the DNS" is a little too vague. If we were to implement
a solution that did not protect against DoS attacks (as is very likely), 
then we could be deemed to have failed "to secure the DNS".

Thanks for the pointer to XKMS. I will read up on it.

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

As soon as one freezes a design, it becomes obsolete in
terms of its concepts.
    --Brooks, p.9