home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
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==--
home | help | back | first | fref | pref | prev | next | nref | lref | last | post |