[148033] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Greg)
Tue Nov 5 18:17:01 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
In-Reply-To: <20131105180849.GA19326@vacation.karoshi.com.>
Date: Tue, 5 Nov 2013 13:39:26 -0500
To: bmanning@vacation.karoshi.com
Cc: "cryptography@metzdowd.com List" <cryptography@metzdowd.com>,
Bill Stewart <bill.stewart@pobox.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4207037602673249078==
Content-Type: multipart/signed; boundary="Apple-Mail=_886BA61D-4AF2-4398-B128-78107389AFA4"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_886BA61D-4AF2-4398-B128-78107389AFA4
Content-Type: multipart/alternative;
boundary="Apple-Mail=_1AA68DB1-2E16-4EC7-BBCE-C20CB230464C"
--Apple-Mail=_1AA68DB1-2E16-4EC7-BBCE-C20CB230464C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Nov 5, 2013, at 1:08 PM, bmanning@vacation.karoshi.com wrote:
> reading this post suggests you really don't understand DNSSEC at all.
It's possible my understanding has holes in it. Like I said, I've been =
having difficulty finding "good" documentation for it (in quotes because =
"good" means something different to everyone). I've been coming across a =
lot of dead links too, and even links to sites with bad certs (irony).
I've been going off of several documents and articles. One is the one =
originally linked to at the start of this thread, and here are some =
others:
"DNSSEC-bis for complete beginners (like me)": http://ds9a.nl/dnssec=20
"Seven Things You Should Know About DNSSEC": =
http://www.educause.edu/ir/library/pdf/est1001.pdf
"Introduction to DNSSEC": =
http://cai.icann.org/files/ssac/dnssec_explained_marrakech_28jun2006.pdf
And here are some quotes that led me to believe that the root plays a =
significant role.
=46rom "Intro. to DNSSEC":
- "Make sure the root zone key can be trusted"
+- "Pointers in the root zone point to lower zones (com/org/info/de =
etc)"
+- "Each pointer is validated with the previous validated zone key"
- "Only the key for the root zone is needed to validate all the DNSSEC =
keys on the Internet"
- "How to update these keys and propagate them are not done yet"
=46rom "Seven Things...":
- "The effort to implement DNSSEC for the root has renewed a longstand- =
ing debate about where =93control of the Internet=94 resides."
- "With DNSSEC, a series of encryption keys are handed off and =
authenticated=97the second-level domain (SLD) key (from exam- ple.edu) =
is authenticated by the TLD (.edu), and the TLD key is authenticated by =
the root. In this way, when an SLD, its parent TLD, and the root are all =
signed, a chain of trust is created. (Holders of SLDs can implement =
DNSSEC before their TLD or the root is signed, creating so-called =
=93islands of trust=94 that rely on intermediate measures to validate =
their encryption keys.) If the encryption keys don=92t match, DNSSEC =
will fail, but because the system is backwards-compatible, the =
transaction will simply follow standard DNS protocols.
The value of the system will come when the root, the TLDs, and SLDs are =
signed, allowing DNSSEC to be used for all Internet traffic. At that =
point, when DNSSEC fails, users will not be routed to bogus servers, and =
they might also be notified that nonmatching DNSSEC keys prevented their =
transaction from going through."
=46rom "DNSSEC-bis for complete beginners...":
- "The second way is to have an existing 'anchor' sign your keys. In an =
ideal world the root-zone would be the anchor, and everything would flow =
from there."
- "We previously noted that we can designate keys as 'anchors', once we =
have verified their authenticity using non-DNS means. It is =
impracticable to do this for all millions of domains though. So we need =
a way to have trusted keys (anchors) sign further keys, in hopes of one =
day having a signed root."
So... I don't quite understand what you mean by:
> using the islands of trust model, _any_ client can trust any keys they =
choose
That sounds like manually adding root certs to your system's keychain to =
me. Nobody (other they neck-beards) does that. In practice, browsers =
come with pinned certs that they trust, and any of these root certs can =
say "yes". How will DNSSEC work in practice for users?
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
--Apple-Mail=_1AA68DB1-2E16-4EC7-BBCE-C20CB230464C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Nov =
5, 2013, at 1:08 PM, <a =
href=3D"mailto:bmanning@vacation.karoshi.com">bmanning@vacation.karoshi.co=
m</a> wrote:<div><br><div><blockquote type=3D"cite">reading this post =
suggests you really don't understand DNSSEC at =
all.<br></blockquote><div><br></div>It's possible my understanding has =
holes in it. Like I said, I've been having difficulty finding "good" =
documentation for it (in quotes because "good" means something different =
to everyone). I've been coming across a lot of dead links too, and even =
links to sites with bad certs (irony).<div><br></div><div>I've been =
going off of several documents and articles. One is the one originally =
linked to at the start of this thread, and here are some =
others:</div><div><br></div><div>"DNSSEC-bis for complete beginners =
(like me)": <a =
href=3D"http://ds9a.nl/dnssec">http://ds9a.nl/dnssec</a> </div><div><=
div>"Seven Things You Should Know About DNSSEC": <a =
href=3D"http://www.educause.edu/ir/library/pdf/est1001.pdf">http://www.edu=
cause.edu/ir/library/pdf/est1001.pdf</a></div><div>"Introduction to =
DNSSEC": <a =
href=3D"http://cai.icann.org/files/ssac/dnssec_explained_marrakech_28jun20=
06.pdf">http://cai.icann.org/files/ssac/dnssec_explained_marrakech_28jun20=
06.pdf</a></div><div><br></div><div>And here are some quotes that led me =
to believe that the root plays a significant =
role.</div><div><br></div><div>=46rom "Intro. to =
DNSSEC":</div><div><br></div></div><blockquote style=3D"margin: 0 0 0 =
40px; border: none; padding: 0px;"><div><div>- "Make sure the root zone =
key can be trusted"</div></div><div><div>+- "Pointers in the root zone =
point to lower zones (com/org/info/de etc)"</div></div><div><div>+- =
"Each pointer is validated with the previous validated zone =
key"</div></div><div><div>- "Only the key for the root zone is needed to =
validate all the DNSSEC keys on the =
Internet"</div></div><div><div>- "How to update these keys and propagate =
them are not done yet"</div></div></blockquote><div><div><br =
class=3D"webkit-block-placeholder"></div><div>=46rom "Seven =
Things...":</div><div><br></div></div><blockquote style=3D"margin: 0 0 0 =
40px; border: none; padding: 0px;"><div><div>- "The effort to =
implement DNSSEC for the root has renewed a longstand- ing debate =
about where =93control of the Internet=94 =
resides."</div></div><div><br></div><div>- "With DNSSEC, a series of =
encryption keys are handed off and authenticated=97the second-level =
domain (SLD) key (from exam- <a href=3D"http://ple.edu">ple.edu</a>) =
is authenticated by the TLD (.edu), and the TLD key =
is authenticated by the root. In this way, when an SLD, its =
parent TLD, and the root are all signed, a chain of trust is =
created. (Holders of SLDs can implement DNSSEC before their TLD or =
the root is signed, creating so-called =93islands of trust=94 that =
rely on intermediate measures to validate their encryption keys.) =
If the encryption keys don=92t match, DNSSEC will fail, but because =
the system is backwards-compatible, the transaction will simply =
follow standard DNS protocols.</div><br>The value of the system will =
come when the root, the TLDs, and SLDs are signed, allowing DNSSEC =
to be used for all Internet traffic. At that point, when DNSSEC fails, =
users will not be routed to bogus servers, and they might also =
be notified that nonmatching DNSSEC keys prevented their =
transaction from going =
through."</blockquote><div><div><br></div><div>=46rom "DNSSEC-bis for =
complete =
beginners...":</div><div><br></div></div></div></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: =
0px;"><div><div><div><div>- "The second way is to have an existing =
'anchor' sign your keys. In an ideal world the root-zone would be =
the anchor, and everything would flow from =
there."</div></div></div></div><div>- "We previously noted that we can =
designate keys as 'anchors', once we have verified their =
authenticity using non-DNS means. It is impracticable to do this =
for all millions of domains though. So we need a way to have =
trusted keys (anchors) sign further keys, in hopes of one day having a =
signed root."</div></blockquote><div><div><br></div><div>So... I don't =
quite understand what you mean by:</div><div><br></div><div><blockquote =
type=3D"cite">using the islands of trust model, _any_ client can trust =
any keys they choose</blockquote></div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">That sounds like manually adding root =
certs to your system's keychain to me. Nobody (other they neck-beards) =
does that. In practice, browsers come with pinned certs that they trust, =
and any of these root certs can say "yes". How will DNSSEC work in =
practice for users?</div><div apple-content-edited=3D"true"><br></div><div=
apple-content-edited=3D"true">- Greg</div><div =
apple-content-edited=3D"true">
<br>--<br>Please do not email me anything that you are =
not comfortable also sharing with the =
NSA.</div></div></body></html>=
--Apple-Mail=_1AA68DB1-2E16-4EC7-BBCE-C20CB230464C--
--Apple-Mail=_886BA61D-4AF2-4398-B128-78107389AFA4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBCgAGBQJSeTthAAoJEKFrDougX6FkYzYH/RuqI1tmFYXWoz6yMv6mIb8H
qyW+BEUnvpKJpHWNGteibbAyP/DJaxIH8QqltrVvDHw/0/LFG8uwX1UgNbrwtGu5
wlbt+BS4BHelbFhlZaNuOMcrLNGBu1ZECNRYQzuDbRqXBF5dea2kvJ/OGyYT2j7Y
DTIvnRf5HNv8VXrpECG2PCwdAvF3pJMJll6aU74JjesxrhZZVbC1tVJx+IxPNFya
/qDk4sW2D3/S7CotX4C9mrNOfFBzQ8bTicdcOVVeQ0DNtOvry3P1aTGoGv9roAnH
4gw8b532xIG7qmsLuaBzLCAPPfsHAgrXwyCBbu+27UgT1t6O2WAYuMsql/maIQM=
=me1d
-----END PGP SIGNATURE-----
--Apple-Mail=_886BA61D-4AF2-4398-B128-78107389AFA4--
--===============4207037602673249078==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============4207037602673249078==--
