In message <AANLkTinbTpvJLQsL87V5xBd0Kh_HN+t1WX2MhdfY23hO@xxxxxxxxxxxxxx>, 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@xxxxxxxx> wrote: > > > On 28 Sep 2010, at 02:20, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote: > > > > On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch < <dot@xxxxxxxx>dot@xxxxxxxx>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@xxxxxxxx> <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@xxxxxxxx";>dot@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@xxxxxxxxx"; target=3D= > "_blank">hallam@xxxxxxxxx</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@xxxxxxxx"; target=3D= > "_blank"></a><a href=3D"mailto:dot@xxxxxxxx"; target=3D"_blank">dot@xxxxxxxx= > </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@xxxxxxxx"; target= > =3D"_blank">dot@xxxxxxxx</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@xxxxxxxx > 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@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf