[147981] in cryptography@c2.net mail archive
[Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Greg)
Mon Nov 4 01:12:50 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
Date: Sun, 3 Nov 2013 23:33:37 -0500
To: "cryptography@metzdowd.com List" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7083023553655892279==
Content-Type: multipart/signed; boundary="Apple-Mail=_239460E9-2E8C-438D-83D0-B2179326A4D5"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_239460E9-2E8C-438D-83D0-B2179326A4D5
Content-Type: multipart/alternative;
boundary="Apple-Mail=_440A202A-2EB0-4F31-949B-5B81CBDFC0BC"
--Apple-Mail=_440A202A-2EB0-4F31-949B-5B81CBDFC0BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
In all my readings on it I kept walking away thinking that I understood =
its purpose, but I'd then come back at myself with the same question: =
what does it give us over HTTPS?
I kept not being able to answer this question so I searched more, and =
eventually stumbled across these two comments on an article about =
DNSSEC:
http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5830
http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5841
Selected quotes:
Unfortunately, DNSSEC isn't actually providing additional security =
against a genuine MITM attack: SSL/TLS is still the weak link in the =
chain when DNSSEC is used!
DNSSEC plus SSL/TLS is therefore not defence in depth against general =
MITM attacks.=20
[..]
No, that's precisely wrong. Cache poisoning isn't a serious threat if =
SSL/TLS is working correctly. In the presence of functional SSL/TLS, DNS =
cache poisoning can only produce a denial of service attack. The =
scenario we're trying to prevent is, "A thinks he is talking with B, but =
is actually talking with C." Cache poisoning can give A the address of C =
instead of B, which is a start, but C can't pass himself off as B unless =
he compromises the SSL/TLS process.
SSL/TLS provides end-to-end security. It catches DNS forgery. It catches =
route hijacking. It catches an arbitrary man in the middle. If SSL/TLS =
is working, every security compromise that DNSSEC can prevent has =
already been covered, and then some.=20
What say you list? To me, the DNSSEC thing seems like it might be mostly =
a waste of a bunch of people's time.
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
--Apple-Mail=_440A202A-2EB0-4F31-949B-5B81CBDFC0BC
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;">In all =
my readings on it I kept walking away thinking that I understood its =
purpose, but I'd then come back at myself with the same question: what =
does it give us over HTTPS?<div><br></div><div>I kept not being able to =
answer this question so I searched more, and eventually stumbled across =
these two comments on an article about =
DNSSEC:</div><div><br></div><div><a =
href=3D"http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#583=
0">http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5830</a>=
</div><div><a =
href=3D"http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#584=
1">http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5841</a>=
</div><div><div><br class=3D"webkit-block-placeholder"></div><div>Selected=
quotes:</div><div><br></div></div><blockquote style=3D"margin: 0 0 0 =
40px; border: none; padding: 0px;"><div><div><p>Unfortunately, <b>DNSSEC =
isn't actually providing additional security against a genuine MITM =
attack</b>: SSL/TLS is still the weak link in the chain when DNSSEC is =
used!
</p><p>
DNSSEC plus SSL/TLS is therefore <em>not</em> defence in depth against =
general MITM attacks. </p></div></div></blockquote><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: =
0px;"><div><div>[..]</div></div><div><br></div><div><p>No, that's =
precisely wrong. Cache poisoning isn't a serious threat if=20
SSL/TLS is working correctly. In the presence of functional SSL/TLS, DNS
cache poisoning can only produce a denial of service attack. The=20
scenario we're trying to prevent is, "A thinks he is talking with B, but
is actually talking with C." Cache poisoning can give A the address of =
C
instead of B, which is a start, but C can't pass himself off as B=20
unless he compromises the SSL/TLS process.
</p><p>
SSL/TLS provides end-to-end security. It catches DNS forgery. It catches
route hijacking. It catches an arbitrary man in the middle. If SSL/TLS=20=
is working, every security compromise that DNSSEC can prevent has=20
already been covered, and then =
some. </p></div></blockquote><div><div><br =
class=3D"webkit-block-placeholder"></div><div>What say you list? To me, =
the DNSSEC thing seems like it might be mostly a waste of a bunch of =
people's time.</div><div><br></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></body></html>=
--Apple-Mail=_440A202A-2EB0-4F31-949B-5B81CBDFC0BC--
--Apple-Mail=_239460E9-2E8C-438D-83D0-B2179326A4D5
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
iQEcBAEBCgAGBQJSdyOkAAoJEKFrDougX6FkPCgIAJilVit5dD+gLcKs6YaWfhrp
FqumAZmudv1Mooz3IlG1Wdz29SxTd1THCWNSBdIZNgrRPeuPG33J4zZ5fU7g8VRG
e+Zr4SYnjquHKVPXqCbfNVhUwGWOyP+wI4lEIl1LTQL/4mhGzx62YBqhCRUei7fR
f+7cxdiRx3p17la+bf3fSxVbrUxOLXL98L/G15c8GGc2K3kHljwvFCRVACIPrl0c
rqMb+MU7ESwpLaZfsBX0VM62YE2W14rDPTj+OpheO/B8r40DQfVQDkX2I+x/XIrX
CovdzOB2OLYqV2jOfm1znzFUBtZYJ2wViyJzas45u2ujOBHkumCCErOluvbMSao=
=BgRy
-----END PGP SIGNATURE-----
--Apple-Mail=_239460E9-2E8C-438D-83D0-B2179326A4D5--
--===============7083023553655892279==
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
--===============7083023553655892279==--
