[147984] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Greg)
Mon Nov 4 12:24:45 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
In-Reply-To: <CA+cU71mfGPpQothnVRBWvempr-nMcTvxCy_YbmvO0CeO4xO6nQ@mail.gmail.com>
Date: Mon, 4 Nov 2013 10:33:11 -0500
To: Tom Ritter <tom@ritter.vg>
Cc: "cryptography@metzdowd.com List" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2764722022895848945==
Content-Type: multipart/signed; boundary="Apple-Mail=_4CB29DEA-76D0-4A24-B63B-1551B3F81365"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_4CB29DEA-76D0-4A24-B63B-1551B3F81365
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
> It's true as we bolt more and more stuff into HTTP Headers (HSTS,
> Public Key Pinning, etc) the value of DNSSEC _for HTTPS_ goes down.
> But there is still value there to be gained for other protocols,
> nearly all of which bootstrap off DNS.
I'm curious, what are these other protocols, and why can't they be =
secured simply by using SSL/TLS + some type of cert. verification?
Let's say that they can, and that it takes 1000 man hours to do this. =
Let's also assume that it takes 10x as much time to implement widespread =
DNSSEC use. Then why are we wasting all those man hours on implementing =
DNSSEC instead of using them to add SSL/TLS + cert. verification to =
other protocols?
Why is anyone still using HTTP?!? It's 2013!
Why does it cost any money to get an HTTPS cert?
These seem like more pressing problems to me.
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
On Nov 4, 2013, at 7:36 AM, Tom Ritter <tom@ritter.vg> wrote:
> On 3 November 2013 23:33, Greg <greg@kinostudios.com> wrote:
>> 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
> DNS does not provide authenticity, DNSSEC does. Not everything we do
> online uses SSL, so while many protocols have some amount of
> authenticity built in to them (each flawed in their own way, as
> Zooko's Triangle dictates some practical limits) - DNSSEC lets us
> bootstrap authenticity for any protocol. "The person you want to talk
> to is [here] and he will use [this key fingerprint]."
>=20
>=20
>> 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.
>=20
> DNSSEC prevents cache poisoning, when used correctly. And SSL/TLS does
> not protect HTTP, which I would venture is a laaaaarge percentage of
> web traffic, even when SSL is available.
>=20
> And if you argue "Well, the HTTP problem can be solved by HSTS" I will
> say "Okay, how do you securely communicate HSTS to a host to which the
> answers are: 'Hope the user isn't owned the first time', 'Bake
> preloaded HSTS into every browser', or 'Securely transmit HSTS
> information using some other protocol like DNS."
>=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
> It's true as we bolt more and more stuff into HTTP Headers (HSTS,
> Public Key Pinning, etc) the value of DNSSEC _for HTTPS_ goes down.
> But there is still value there to be gained for other protocols,
> nearly all of which bootstrap off DNS. The other big win for HTTP
> we'll see is the ability to use self-signed certificates via DANE,
> which relies on DNSSEC.
>=20
> -tom
--Apple-Mail=_4CB29DEA-76D0-4A24-B63B-1551B3F81365
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
iQEcBAEBCgAGBQJSd747AAoJEKFrDougX6FkVNEH/06iIt9ydYj2+uyGEmLvqp7R
39pPYy8Drn0w9Q6w6aORCoqSEWJVAAxG7ZfZRwlWVHcuzJrNAQveFBQlTSHH/OOc
YKB9CJMp/sV/BS435CZRt3Q2p/LGbh5EALr8TPL/VaagHWQyS9GBWBjCk2MqqqGR
HSY05TObQs8Q0HuNbO5AI1MUSXIQuqbH0pAi6oP84h+7Uc/Mlrr7QR6KgNRFPGOF
e6FxOH+q966Dn/44VJBjz6BaULPW7IPx3N0XnHxxO+JrQakFK3JGrdF4LfVQTr57
brDAZHbXeDFEr1/csus1+0DgEEI1tes/c6PSXmJXXmPLf8PzDNXKoJFimOQb2Hw=
=cV9a
-----END PGP SIGNATURE-----
--Apple-Mail=_4CB29DEA-76D0-4A24-B63B-1551B3F81365--
--===============2764722022895848945==
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
--===============2764722022895848945==--
