[148035] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Greg)
Tue Nov 5 18:18:25 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
In-Reply-To: <20131105185604.GE19326@vacation.karoshi.com.>
Date: Tue, 5 Nov 2013 17:23:53 -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
--===============6577492020378963222==
Content-Type: multipart/signed; boundary="Apple-Mail=_6DFA5741-720E-4200-913F-AEF2E161E515"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_6DFA5741-720E-4200-913F-AEF2E161E515
Content-Type: multipart/alternative;
boundary="Apple-Mail=_36D1CD31-16DB-463F-B2F3-67381FB2ED86"
--Apple-Mail=_36D1CD31-16DB-463F-B2F3-67381FB2ED86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> Check out that _-ANY-_ in the last sentence....
This is a bit too vague for me to understand how it would work in =
practice. Perhaps the RFC goes into more detail, but I'd rather spend my =
time on researching less broken systems right now.
Someone sent me a link that led me to this page on DNSSEC failures, and =
some choice quotes:
http://ianix.com/pub/dnssec-outages.html
Here's two from Moxie (now I know I'm in good company):
"So unfortunately the DNSSEC trust relationships depend on sketchy =
organizations and governments, just like the current CA system. Worse, =
far from providing increased trust agility, DNSSEC-based systems =
actually provide reduced trust agility."
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
"We had this map of the EFF's SSL Observatory data on what countries are =
currently capable of intercepting secure communication under the CA =
system. Under [DNSSEC/DANE], it would look like this."
https://www.youtube.com/watch?v=3DZ7Wl2FW2TcA#t=3D33m43s
(He shows a completely red map, indicating all countries)
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
On Nov 5, 2013, at 1:56 PM, bmanning@vacation.karoshi.com wrote:
>=20
> every one of those organizations has a vested interest in promoting =
centralized control=20
> of the trust heirarchy.
>=20
> =
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.=
html
> http://tools.ietf.org/html/rfc5011 -- particularly the Intro.
>=20
> As part of the reality of fielding DNSSEC (Domain Name System
> Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community =
has
> come to the realization that there will not be one signed name =
space,
> but rather islands of signed name spaces each originating from
> specific points (i.e., 'trust points') in the DNS tree. Each of
> those islands will be identified by the trust point name, and
> validated by at least one associated public key. For the purpose of
> this document, we'll call the association of that name and a
> particular key a 'trust anchor'. A particular trust point can have
> more than one key designated as a trust anchor.
>=20
> For a DNSSEC-aware resolver to validate information in a DNSSEC
> protected branch of the hierarchy, it must have knowledge of a trust
> anchor applicable to that branch. It may also have more than one
> trust anchor for any given trust point. Under current rules, a =
chain
> of trust for DNSSEC-protected data that chains its way back to ANY
> known trust anchor is considered 'secure'.
>=20
> ----
>=20
> Check out that _-ANY-_ in the last sentence....
>=20
>=20
>=20
> On Tue, Nov 05, 2013 at 01:39:26PM -0500, Greg wrote:
>> On Nov 5, 2013, at 1:08 PM, bmanning@vacation.karoshi.com wrote:
>>=20
>>> reading this post suggests you really don't understand DNSSEC at =
all.
>>=20
>> 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).
>>=20
>> 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:
>>=20
>> "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
>>=20
>> And here are some quotes that led me to believe that the root plays a =
significant role.
>>=20
>> =46rom "Intro. to DNSSEC":
>>=20
>> - "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"
>>=20
>> =46rom "Seven Things...":
>>=20
>> - "The effort to implement DNSSEC for the root has renewed a =
longstand- ing debate about where b=1Ccontrol of the Internetb=1D =
resides."
>>=20
>> - "With DNSSEC, a series of encryption keys are handed off and =
authenticatedb=14the 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 =
b=1Cislands of trustb=1D that rely on intermediate measures to validate =
their encryption keys.) If the encryption keys donb=19t match, DNSSEC =
will fail, but because the system is backwards-compatible, the =
transaction will simply follow standard DNS protocols.
>>=20
>> 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."
>>=20
>> =46rom "DNSSEC-bis for complete beginners...":
>>=20
>> - "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."
>>=20
>> So... I don't quite understand what you mean by:
>>=20
>>> using the islands of trust model, _any_ client can trust any keys =
they choose
>>=20
>>=20
>> 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?
>>=20
>> - Greg
>>=20
>> --
>> Please do not email me anything that you are not comfortable also =
sharing with the NSA.
--Apple-Mail=_36D1CD31-16DB-463F-B2F3-67381FB2ED86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><blockquote type=3D"cite">Check out that _-ANY-_ in =
the last sentence....<br></blockquote><div><br></div>This is a bit too =
vague for me to understand how it would work in practice. Perhaps the =
RFC goes into more detail, but I'd rather spend my time on researching =
less broken systems right now.<div><br></div><div>Someone sent me a link =
that led me to this page on DNSSEC failures, and some choice =
quotes:</div><div><br></div><div><a =
href=3D"http://ianix.com/pub/dnssec-outages.html">http://ianix.com/pub/dns=
sec-outages.html</a></div><div><br></div><div>Here's two from Moxie (now =
I know I'm in good company):</div><div><br></div><div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><i>"So
unfortunately the DNSSEC trust relationships depend on sketchy
organizations and governments, just like the current CA system.
Worse, far from providing increased trust agility, DNSSEC-based systems
actually provide reduced trust agility."</i></div><div><a =
href=3D"http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticit=
y/">http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/</=
a></div><div><i><br></i></div></blockquote></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><i>"We =
had this map of the EFF's SSL Observatory
data on what countries are currently capable of intercepting secure
communication under the CA system. Under [DNSSEC/DANE], it would look
like this."</i></div><div><a =
href=3D"https://www.youtube.com/watch?v=3DZ7Wl2FW2TcA#t=3D33m43s">https://=
www.youtube.com/watch?v=3DZ7Wl2FW2TcA#t=3D33m43s</a></div><div><br></div><=
div>(He shows a completely red map, indicating all =
countries)</div></blockquote><div><div><br =
class=3D"webkit-block-placeholder"></div><div>- Greg</div><div>
<br>--<br>Please do not email me anything that you are =
not comfortable also sharing with the NSA.<br>
</div>
<br><div><div>On Nov 5, 2013, at 1:56 PM, <a =
href=3D"mailto:bmanning@vacation.karoshi.com">bmanning@vacation.karoshi.co=
m</a> wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"font-size: 14px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><br>every one of those =
organizations has a vested interest in promoting centralized =
control<span class=3D"Apple-converted-space"> </span><br>of the =
trust heirarchy.<br><br><a =
href=3D"http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2=
/dnssec.html">http://www.cisco.com/web/about/ac123/ac147/archived_issues/i=
pj_7-2/dnssec.html</a><br><a =
href=3D"http://tools.ietf.org/html/rfc5011">http://tools.ietf.org/html/rfc=
5011</a><span class=3D"Apple-converted-space"> </span> -- =
particularly the Intro.<br><br>As part of the reality of fielding DNSSEC =
(Domain Name System<br> Security Extensions) [RFC4033] =
[RFC4034] [RFC4035], the community has<br> come to the =
realization that there will not be one signed name =
space,<br> but rather islands of signed name spaces each =
originating from<br> specific points (i.e., 'trust points') =
in the DNS tree. Each of<br> those islands will be =
identified by the trust point name, and<br> validated by at =
least one associated public key. For the purpose =
of<br> this document, we'll call the association of that name =
and a<br> particular key a 'trust anchor'. A particular =
trust point can have<br> more than one key designated as a =
trust anchor.<br><br> For a DNSSEC-aware resolver to validate =
information in a DNSSEC<br> protected branch of the =
hierarchy, it must have knowledge of a trust<br> anchor =
applicable to that branch. It may also have more than =
one<br> trust anchor for any given trust point. Under =
current rules, a chain<br> of trust for DNSSEC-protected data =
that chains its way back to ANY<br> known trust anchor is =
considered 'secure'.<br><br>----<br><br>Check out that _-ANY-_ in the =
last sentence....<br><br><br><br>On Tue, Nov 05, 2013 at 01:39:26PM =
-0500, Greg wrote:<br><blockquote type=3D"cite">On Nov 5, 2013, at 1:08 =
PM, <a =
href=3D"mailto:bmanning@vacation.karoshi.com">bmanning@vacation.karoshi.co=
m</a> wrote:<br><br><blockquote type=3D"cite">reading this post suggests =
you really don't understand DNSSEC at all.<br></blockquote><br>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).<br><br>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:<br><br>"DNSSEC-bis for complete beginners (like =
me)": <a href=3D"http://ds9a.nl/dnssec">http://ds9a.nl/dnssec</a><span =
class=3D"Apple-converted-space"> </span><br>"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><br>"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><br><br>And here are some quotes that led me to believe that =
the root plays a significant role.<br><br>=46rom "Intro. to =
DNSSEC":<br><br>- "Make sure the root zone key can be trusted"<br>+- =
"Pointers in the root zone point to lower zones (com/org/info/de =
etc)"<br>+- "Each pointer is validated with the previous validated zone =
key"<br>- "Only the key for the root zone is needed to validate all the =
DNSSEC keys on the Internet"<br>- "How to update these keys and =
propagate them are not done yet"<br><br>=46rom "Seven =
Things...":<br><br>- "The effort to implement DNSSEC for the root has =
renewed a longstand- ing debate about where b=1Ccontrol of the =
Internetb=1D resides."<br><br>- "With DNSSEC, a series of encryption =
keys are handed off and authenticatedb=14the second-level domain (SLD) =
key (from exam-<span class=3D"Apple-converted-space"> </span><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 b=1Cislands of trustb=1D that rely on =
intermediate measures to validate their encryption keys.) If the =
encryption keys donb=19t match, DNSSEC will fail, but because the system =
is backwards-compatible, the transaction will simply follow standard DNS =
protocols.<br><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."<br><br>=46rom =
"DNSSEC-bis for complete beginners...":<br><br>- "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."<br>- "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."<br><br>So... I don't quite understand =
what you mean by:<br><br><blockquote type=3D"cite">using the islands of =
trust model, _any_ client can trust any keys they =
choose<br></blockquote><br><br>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?<br><br>- Greg<br><br>--<br>Please do not email me =
anything that you are not comfortable also sharing with the =
NSA.</blockquote></div></blockquote></div><br></div></body></html>=
--Apple-Mail=_36D1CD31-16DB-463F-B2F3-67381FB2ED86--
--Apple-Mail=_6DFA5741-720E-4200-913F-AEF2E161E515
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
iQEcBAEBCgAGBQJSeW/5AAoJEKFrDougX6FkOuYH/1rGC4umaLCNqN8UbbMj32b/
XbBiyOCH3xWS4S5nJDvip3Rh9vrjvD91VOVDFoZGfIwbVmePmZU7rWq9vDw2eGbv
WD4E98cjaOoFR8oORitUOCyrcWEqS7WrWU29qA0JIy0r+43mH4e0XV+iEin5MiBl
znoJEsHms15mfHgaKcJm/CMCXiZd6vJHu9kYQ7fZMgtA8OhAPwPODZm/3Yhlg4/N
SzcyrX1r4VMrZKAYxuO2LcIswGIeCaYipzN6sdNoL9mcKH9/Ra97k9mc0OQsG90X
+7DeulgYFElGoBnkP9AnlBlZWbayL3SsiQFWeONvoWVn+1BaMy2czIBmhFkzKfs=
=crcQ
-----END PGP SIGNATURE-----
--Apple-Mail=_6DFA5741-720E-4200-913F-AEF2E161E515--
--===============6577492020378963222==
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
--===============6577492020378963222==--
