[dnsext] DPLS and CAA Drafts

[Phillip Hallam-Baker <[e-mail]>]

All,

These are not quite in the form that I would like to have them, but the
drafts cut-off is today so I had to submit. I have submitted two drafts that
make use of the DNS and DNSSEC in a slightly different way to the normal
model


The first is a mechanism to support a TLS-like transport encryption but
tuned to the specific needs of DNS traffic. Neither TLS nor DTLS looks like
a good fit to me. IPSEC requires the server to maintain state in ways that
make it totally impractical for securing traffic to a resolver serving a
million clients.

DNSCurve treads some of the same ground but in ways that appear to me to be
totally unsympathetic to the existing infrastructure of DNS.

One important consequence of this type of approach is that it enables a
model in which the DNS recursive resolver is a chosen, trusted service
rather than the client promiscuously taking service from the nearest DNS
resolver because it is there. This in turn means that the DNS resolver can
support requests at a higher level than in the traditional DNS model and
this allows for operations such as enhanced discovery to be supported at the
resolver level rather than the client.

http://www.ietf.org/id/draft-hallambaker-dpls-00.txt

I did look into the use of the existing DNS key exchange mechanism. But it
is a design from 1999 and much has changed since. At the time we were still
dancing round the RSA patent encumbrances. In house renovation terms it is a
teardown in my view. TLS has all the mechanism we need already and most
DNSSEC implementations are layered on a platform that already has a full TLS
stack.


The second is a proposal to allow Certification Authorities to avoid
mis-issue of certificates. If you have a large company like IBM it may well
not be apparent which bit of IBM should be contacted when a certificate
request arrives. This is of course quite easy for a CA that is the
authorized CA to serve the whole of IBM and thus *.ibm.com. But this is a
problem for all the other CAs who have not been contacted and do not know
who the authorized party for the subject is.

The proposal made is not dependent on DNSSEC but works a lot better with
DNSSEC. I would like to try to move ahead with this as soon as possible
because that will provide a proof point showing that DNSSEC is already
delivering value.

http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt
Now, obviously this type of proposal can be extended as a general security
policy mechanism. But that is a lot more work and has far more moving parts.
I prefer to concentrate on getting some runs on the board for the concept of
using DNSSEC to strengthen existing PKI systems.


-- 
Website: http://hallambaker.com/