[148011] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary + a bad idea?
daemon@ATHENA.MIT.EDU (Greg)
Mon Nov 4 23:37:25 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
Date: Mon, 4 Nov 2013 20:18:18 -0500
To: "cryptography@metzdowd.com List" <cryptography@metzdowd.com>
In-Reply-To: <20131104205559.GO2976@mournblade.imrryr.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2412632955419112248==
Content-Type: multipart/signed; boundary="Apple-Mail=_A9B16001-19A1-428F-8553-9BCBFA8E52C7"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_A9B16001-19A1-428F-8553-9BCBFA8E52C7
Content-Type: multipart/alternative;
boundary="Apple-Mail=_D723F16A-8D3F-49DE-ADC4-D61DCAB07DE8"
--Apple-Mail=_D723F16A-8D3F-49DE-ADC4-D61DCAB07DE8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> When one defines all problems to be nails, the solution will always
> be a hammer, and people making axes will appear to be wasting their
> time.
Here, I agree with you.
Where we disagree is in what we consider to be nails, hammers, and axes.
Finding good documentation on DNSSEC has proven to be difficult, but as =
far as I can tell, DNSSEC appears to be a sort of frankenstein =
re-implementation of the authentication aspects of SSL/TLS.
I've yet to see any compelling case that this is not so.
> - You're trying to secure HTTP over TLS.
Well, duh. That's the bare minimum.
> - You assume the destination website has a certificate from a trusted =
public CA.
> - You assume that the HTTPS client does not trust any rogue CAs.
> - You assume that the CA issued the certificate based on criteria =
stronger
> than verifying that the requestor seems to control the DNS for the =
domain.
> - You assume that CA certificates assert a stronger claim than domain
> ownership, i.e. some sort of brand validation, as in EV certificates.
> - You're only trying to secure the small minority of HTTP sites with =
EV
> certificates for brand-name domains.
These are all basically the same issue (as far as I can tell), not five =
separate ones.
This issue (trust), has not been solved by HTTPS.
HTTPS does not guarantee trust.
Neither does DNSSEC though! (as far as I can tell)
DNSSEC appears to be doing basically the same type of "chain of trust" =
thing that CA's provide (and in a terribly broken way, I might add).
As far as I've been able to understand, it wants a trusted "root":
"So we need a way to have trusted keys (anchors) sign further keys, in =
hopes of one day having a signed root."
That's crazy-talk!
Who wants "a signed root"?!? I don't! Neither should anyone else!
Haven't we learned from HTTPS that trusting root CAs is a bad idea?
DNSSEC doesn't:
- encrypt your requests
- encrypt your data
- protect you from compromised root keys
What good is it?
Private keys should be treated nonchalantly. If one is compromised, the =
consequences shouldn't be dire or a pain-in-the-a**. Why? Because =
private key compromise _will happen_, especially with systems like =
DNSSEC and HTTPS that put so much importance on them.
And these guys are seriously trying to coordinate an "international =
effort" to switch to such a broken system?? Give me a break!
I can only hope that the complexity of DNSSEC, and the quarreling over =
who gets control over the master keys will keep it from ever being =
adopted or taken seriously.
The internet is a *NET*work. There is no place on a network for a single =
point of failure, and any actor burdened with the responsibility of =
holding "ultimate trust" _automatically_ and _necessarily_ becomes =
untrustworthy.
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
On Nov 4, 2013, at 3:55 PM, Viktor Dukhovni <cryptography@dukhovni.org> =
wrote:
> On Sun, Nov 03, 2013 at 11:33:37PM -0500, Greg wrote:
>=20
>> 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?
>=20
> Nothing: provided:
>=20
> - You're trying to secure HTTP over TLS.
> - You assume the destination website has a certificate from a trusted =
public CA.
> - You assume that the HTTPS client does not trust any rogue CAs.
> - You assume that the CA issued the certificate based on criteria =
stronger
> than verifying that the requestor seems to control the DNS for the =
domain.
> - You assume that CA certificates assert a stronger claim than domain
> ownership, i.e. some sort of brand validation, as in EV certificates.
> - You're only trying to secure the small minority of HTTP sites with =
EV
> certificates for brand-name domains.
> - If your protocol is not HTTP, there is no DNS-based indirection from
> client destination to server domain as with MX or SRV records.
> - ...
>=20
> When one defines all problems to be nails, the solution will always
> be a hammer, and people making axes will appear to be wasting their
> time.
>=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.
>=20
> Perhaps the bunch of people "wasting" time on DNSSEC are interested
> in a broader class of problems.
>=20
> --=20
> Viktor.
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
--Apple-Mail=_D723F16A-8D3F-49DE-ADC4-D61DCAB07DE8
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;"><div =
apple-content-edited=3D"true"><blockquote type=3D"cite">When one defines =
all problems to be nails, the solution will always<br>be a hammer, and =
people making axes will appear to be wasting =
their<br>time.<br></blockquote><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Here, I agree with you.</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Where we disagree is in what we consider =
to be nails, hammers, and axes.</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Finding good documentation on DNSSEC has =
proven to be difficult, but as far as I can tell, DNSSEC appears to be a =
sort of frankenstein re-implementation of the authentication aspects of =
SSL/TLS.</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">I've yet to see any compelling case that =
this is not so.</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true"><blockquote type=3D"cite">- You're trying =
to secure HTTP over TLS.</blockquote><br></div><div =
apple-content-edited=3D"true">Well, duh. That's the bare =
minimum.</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true"><blockquote type=3D"cite">- You assume the =
destination website has a certificate from a trusted public CA.<br>- You =
assume that the HTTPS client does not trust any rogue CAs.<br>- You =
assume that the CA issued the certificate based on criteria =
stronger<br> than verifying that the requestor seems to control the =
DNS for the domain.<br>- You assume that CA certificates assert a =
stronger claim than domain<br> ownership, i.e. some sort of brand =
validation, as in EV certificates.<br></blockquote></div><div =
apple-content-edited=3D"true"><blockquote type=3D"cite">- You're only =
trying to secure the small minority of HTTP sites with =
EV<br> certificates for brand-name =
domains.<br></blockquote><div><br></div></div><div =
apple-content-edited=3D"true">These are all basically the same issue (as =
far as I can tell), not five separate ones.</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">This issue (trust), has not been solved by =
HTTPS.</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">HTTPS does not guarantee trust.</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Neither does DNSSEC though! (as far as I =
can tell)</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">DNSSEC appears to be doing basically the =
same type of "chain of trust" thing that CA's provide (and in a terribly =
broken way, I might add).</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">As far as I've been able to understand, it =
wants a trusted "root":</div><div =
apple-content-edited=3D"true"><br></div></div><blockquote style=3D"margin:=
0 0 0 40px; border: none; padding: 0px;"><div =
apple-content-edited=3D"true"><div apple-content-edited=3D"true"><i>"So =
we need a way
to have trusted keys (anchors) sign further keys, in hopes of one =
day having a signed root."</i></div></div></blockquote><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">That's crazy-talk!</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Who wants "a signed root"?!? I don't! =
Neither should anyone else!</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Haven't we learned from HTTPS that =
trusting root CAs is a bad idea?</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">DNSSEC doesn't:</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">- encrypt your requests</div><div =
apple-content-edited=3D"true">- encrypt your data</div><div =
apple-content-edited=3D"true">- protect you from compromised root =
keys</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">What good is it?</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">Private keys should be treated =
nonchalantly. If one is compromised, the consequences shouldn't be dire =
or a pain-in-the-a**. Why? Because private key compromise _will happen_, =
especially with systems like DNSSEC and HTTPS that put so much =
importance on them.</div><div apple-content-edited=3D"true"><br></div><div=
apple-content-edited=3D"true">And these guys are seriously trying to =
coordinate an "international effort" to switch to such a broken system?? =
Give me a break!</div><div apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">I can only hope that the complexity of =
DNSSEC, and the quarreling over who gets control over the master keys =
will keep it from ever being adopted or taken seriously.</div><div =
apple-content-edited=3D"true"><br></div><div =
apple-content-edited=3D"true">The internet is a *<i>NET*work</i>. There =
is no place on a network for a single point of failure, and any actor =
burdened with the responsibility of holding "ultimate trust" =
<b>_automatically_</b> and <b>_necessarily_</b> becomes =
untrustworthy.</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.<br>
</div>
<br><div><div>On Nov 4, 2013, at 3:55 PM, Viktor Dukhovni <<a =
href=3D"mailto:cryptography@dukhovni.org">cryptography@dukhovni.org</a>>=
; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On Sun, Nov 03, 2013 at 11:33:37PM -0500, Greg =
wrote:<br><br><blockquote type=3D"cite">In all my readings on it I kept =
walking away thinking that I<br>understood its purpose, but I'd then =
come back at myself with the<br>same question: what does it give us over =
HTTPS?<br></blockquote><br>Nothing: provided:<br><br>- You're trying to =
secure HTTP over TLS.<br>- You assume the destination website has a =
certificate from a trusted public CA.<br>- You assume that the HTTPS =
client does not trust any rogue CAs.<br>- You assume that the CA issued =
the certificate based on criteria stronger<br> than verifying that =
the requestor seems to control the DNS for the domain.<br>- You assume =
that CA certificates assert a stronger claim than domain<br> =
ownership, i.e. some sort of brand validation, as in EV =
certificates.<br>- You're only trying to secure the small minority of =
HTTP sites with EV<br> certificates for brand-name domains.<br>- =
If your protocol is not HTTP, there is no DNS-based indirection from<br> =
client destination to server domain as with MX or SRV =
records.<br>- ...<br><br>When one defines all problems to be nails, the =
solution will always<br>be a hammer, and people making axes will appear =
to be wasting their<br>time.<br><br><blockquote type=3D"cite">What say =
you list? To me, the DNSSEC thing seems like it might<br>be mostly a =
waste of a bunch of people's time.<br></blockquote><br>Perhaps the bunch =
of people "wasting" time on DNSSEC are interested<br>in a broader class =
of problems.<br><br>-- <br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> =
</span>Viktor.<br>_______________________________________________<br>The =
cryptography mailing list<br><a =
href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br=
>http://www.metzdowd.com/mailman/listinfo/cryptography<br></blockquote></d=
iv><br></body></html>=
--Apple-Mail=_D723F16A-8D3F-49DE-ADC4-D61DCAB07DE8--
--Apple-Mail=_A9B16001-19A1-428F-8553-9BCBFA8E52C7
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
iQEcBAEBCgAGBQJSeEdeAAoJEKFrDougX6Fk9OMH/2wb9JxV9/GAweecZoYR3acv
X8xQQLV7+JGCTGE752vcIoROx++XIfZ4QUI2KRwCxsfV4dPkq+TJA3vZO3+a/IZz
dnqCNtpTOqep1y42EjOs0hW2adSxwDs+2Ch3ox5ttNFWOY+w5gc2PCSEClLHpk0N
YAqkxsZ6qU25q+zd+FIXC+tj1Hff7G6MrYrlhm0myMKSHkzpUa4gJATFpSTC/Qip
Y3An7Xo3wyUZnM4IVBk5ZK8C3J9rPlbhQrNoo9qzshTxF0gT+cIosQCxg5AxzpS/
RI4PaQaahy5T3AVNLhynK9mF1HEPLVFHsoPJo7hbfsu5dw9RoxdIKgnty9aNOhU=
=2ht3
-----END PGP SIGNATURE-----
--Apple-Mail=_A9B16001-19A1-428F-8553-9BCBFA8E52C7--
--===============2412632955419112248==
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
--===============2412632955419112248==--
