[dnsext] DPLS and CAA Drafts

Phillip Hallam-Baker <hallam@gmail.com> Mon, 18 October 2010 22:13 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F27C3A6B18; Mon, 18 Oct 2010 15:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level:
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-rSbE-Fahjw; Mon, 18 Oct 2010 15:13:39 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17A6B3A69AD; Mon, 18 Oct 2010 15:13:39 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P7xqn-000El8-5T for namedroppers-data0@psg.com; Mon, 18 Oct 2010 22:06:37 +0000
Received: from mail-fx0-f52.google.com ([209.85.161.52]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <hallam@gmail.com>) id 1P7xqj-000Eks-9C for namedroppers@ops.ietf.org; Mon, 18 Oct 2010 22:06:33 +0000
Received: by fxm16 with SMTP id 16so1187411fxm.11 for <namedroppers@ops.ietf.org>; Mon, 18 Oct 2010 15:06:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=SikUWwTD119JAvNFu8NNLPAaEpo1CFU5VHGsVfB2wFk=; b=dmvqsJ02zwtgO10rd2XAg0LiVVnwxRwmtSNTkQJh1zRi6cSpeY0dQj2pCnZM4dQewF Ny3FWOtIVMKWW/BTRGa2KfsOSPDbJUMTbhBiSF0iW1R4tol1/EXB9wBeE+5nJ1dv9rpB ONNA8XVlS0oXy9WDMyz9lFzDxIMkje0HsPJ+Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=e85C2ayitgoDtb0sGRyzI4DlMspH3fFpfLEBQ6NrnuquCl/lPy4vCRxfRT3s8eKS9Z MTk5Ms6HVI75pg9NkDhuGaRF6I3XcHSaGSQFE3CLRE8D0p6boNoe+UDkD8kjB94G0Gzf uuvs6coz2j9jetAt7K8lJb06LLe68vbxUWDVg=
MIME-Version: 1.0
Received: by 10.239.151.200 with SMTP id s8mr367708hbb.155.1287439588135; Mon, 18 Oct 2010 15:06:28 -0700 (PDT)
Received: by 10.239.156.141 with HTTP; Mon, 18 Oct 2010 15:06:28 -0700 (PDT)
Date: Mon, 18 Oct 2010 18:06:28 -0400
Message-ID: <AANLkTikXL_6LpH79xmn2-oGnxv5DD9UPq+N+9zakmtPP@mail.gmail.com>
Subject: [dnsext] DPLS and CAA Drafts
From: Phillip Hallam-Baker <hallam@gmail.com>
To: namedroppers <namedroppers@ops.ietf.org>
Content-Type: multipart/alternative; boundary=001485f7cc905211f10492eb637f
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

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/