In message
<AANLkTinbTpvJLQsL87V5xBd0Kh_HN+t1WX2MhdfY23hO(_at_)mail(_dot_)gmail(_dot_)com>,
Phil
lip Hallam-Baker writes:
The most frustrating part about DNSSEC is that trying to pin down what it is
and what it is not, what it is trying to do and what it is not is like
trying to nail jello to a wall.
DNSSEC is a tool. It can be used in lots of ways. It can be configured in
lots of ways.
Whenever an issue is raised with the DNSSEC protocol, someone immediately
shoots back the reply 'well we are not trying to solve that problem'. Which
is of course really easy when there is no clear statement of what real world
security issues that DNSSEC is trying to deal with.
Blocking one attack does not come close to justifying the cost of DNSSEC
deployment.
It's designed to block a whole series of attacks and to be an enabling
tools to do other things which are not possible with a insecure DNS.
Is DLV a part of DNSSEC or not? I am not sure.
DLV fills one of the left to the user how to do this parts of DNSSEC.
How to distribute/configure the trust anchors DNSSEC needs to do
its job. It uses DNSSEC to secure that distribution and requires
one configured trust anchor to boot strap the process. This is
conceptually no different to what IANA did with its ITAR.
This is how it was presented to the IESG when the DLV record was being
allocated.
DLV is presented as being a stopgap, an interim measure to go away with full
DNSSEC deployment.
Which deals with which trust anchors are added and removed from the
collection and when that is done.
What I do know is that I want to use secure DNS in devices that are not
capable of performing public key cryptography. And even if every end point
device is capable of performing RSA2048 operations in acceptable time, I do
not want to push my trust management criteria out to my network endpoints.
Which is perfectly possible to do with DNSSEC + TSIG or DNSSEC + SIG(0) or
DNSSEC + GSS-TSIG or DNSSEC + IPSEC or ....
On Tue, Sep 28, 2010 at 4:23 AM, Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
On 28 Sep 2010, at 02:20, Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com> wrote:
On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch <
<dot(_at_)dotat(_dot_)at>dot(_at_)dotat(_dot_)at>w
rote:
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.
Why not?
Because the root of trust for any enterprise is the enterprise itself. Not
ICANN.
DNSSEC does not require you to use only ICANN's trust anchor. You can also
use your enterprise trust anchor, so you can validate your enterprise DNS
independently of any third party.
(The keyassure work might make this approach to key distribution easier
than running an enterprise X.509 CA. DNSSEC also has the advantage of a
defined trust anchor rollover protocol.)
You can also use third party trust anchors such as the ISC's DLV.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at>
<http://dotat.at/>http://dotat.at/
--
Website: http://hallambaker.com/
--001636e0a79c19803a04915324b4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>The most frustrating part about DNSSEC is that trying to pin down what=
it is and what it is not, what it is trying to do and what it is not is li=
ke trying to nail jello to a wall.</div><div><br></div><div>Whenever an iss=
ue is raised with the DNSSEC protocol, someone immediately shoots back the =
reply 'well we are not trying to solve that problem'. Which is of c=
ourse really easy when there is no clear statement of what real world secur=
ity issues that DNSSEC is trying to deal with.</div>
<div><br></div><div>Blocking one attack does not come close to justifying t=
he cost of DNSSEC deployment.</div><div><br></div><div><br></div><div>Is DL=
V a part of DNSSEC or not? I am not sure.=A0</div><div><br></div><div>DLV i=
s presented as being a stopgap, an interim measure to go away with full DNS=
SEC deployment.=A0</div>
<div><br></div><div>What I do know is that I want to use secure DNS in devi=
ces that are not capable of performing public key cryptography. And even if=
every end point device is capable of performing RSA2048 operations in acce=
ptable time, I do not want to push my trust management criteria out to my n=
etwork endpoints.</div>
<div><br></div><div><br></div><div><br></div>On Tue, Sep 28, 2010 at 4:23 A=
M, Tony Finch <span dir=3D"ltr"><<a
href=3D"mailto:dot(_at_)dotat(_dot_)at">dot(_at_)dot=
at.at</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
<div bgcolor=3D"#FFFFFF"><div class=3D"im"><div><span>On 28 Sep 2010, at 02=
:20, Phillip Hallam-Baker <<a href=3D"mailto:hallam(_at_)gmail(_dot_)com"
target=3D=
"_blank">hallam(_at_)gmail(_dot_)com</a>>
wrote:</span><br></div><blockquote type=
=3D"cite">
<div><div><div><div class=3D"gmail_quote">On Mon, Sep 27, 2010 at 10:48 AM,=
Tony Finch <span dir=3D"ltr"><<a href=3D"mailto:dot(_at_)dotat(_dot_)at"
target=3D=
"_blank"></a><a href=3D"mailto:dot(_at_)dotat(_dot_)at"
target=3D"_blank">dot(_at_)dotat(_dot_)at=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Fri, 24 Sep 2010, Phillip Hallam-Bak=
er wrote:<br>
><br>
> DNSSEC is a mechanism for establishing inter-domain trust. It is not a=
n<br>
> appropriate technology for intra-domain trust.<br>
<br>
</div>Why not?</blockquote></div><br></div><div><span>Because the root of t=
rust for any enterprise is the enterprise itself.<span>=A0</span>Not ICANN.=
</span></div></div></div></blockquote><br></div><span>DNSSEC does not requi=
re you to use only ICANN's trust anchor. You can also use your enterpri=
se trust anchor, so you can validate your enterprise DNS independently of a=
ny third party.</span><div>
<span><br></span></div><div><span>(The keyassure work might make this appro=
ach to key distribution easier than running an enterprise X.509 CA. DNSSEC =
also has the advantage of a defined trust anchor rollover protocol.)<br>
<br></span><div><span>You can also use third party trust anchors such as th=
e ISC's DLV.</span></div><div class=3D"im"><div><span><br><div>Tony.</d=
iv>--<div>f.anthony.n.finch =A0<<a href=3D"mailto:dot(_at_)dotat(_dot_)at"
target=
=3D"_blank">dot(_at_)dotat(_dot_)at</a>> =A0<a href=3D"http://dotat.at/";
target=3D"=
_blank"></a><a href=3D"http://dotat.at/"; target=3D"_blank">http://dotat.at/=
</a></div>
</span></div></div></div></div></blockquote></div><br><br clear=3D"all"><br=
-- <br>Website: <a href=3D"http://hallambaker.com/";>http://hallambaker.com=
/</a><br><br>
--001636e0a79c19803a04915324b4--
--===============1131113753==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--===============1131113753==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf