[147983] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Guido Witmond)
Mon Nov 4 12:22:32 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 04 Nov 2013 11:14:58 +0100
From: Guido Witmond <guido@witmond.nl>
To: cryptography@metzdowd.com
In-Reply-To: <18B88BE7-7E0B-4F6C-A2F6-9AF7E9637306@kinostudios.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5370828958863567797==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="----enig2ENPJDICGQMIQUQMPFXVN"
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2ENPJDICGQMIQUQMPFXVN
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 11/04/13 05:33, Greg 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
>=20
> http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5830=20
> http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/#5841
>=20
> Selected quotes:
>=20
> Unfortunately, *DNSSEC isn't actually providing additional security=20
> against a genuine MITM attack*: SSL/TLS is still the weak link in the
> chain when DNSSEC is used!
>=20
> DNSSEC plus SSL/TLS is therefore /not/ defence in depth against=20
> general MITM attacks.
I think these quotes are misleading. DNSSEC is designed to prevent
DNS-related attacks, reducing cache poisoning to a DoS-attack.
>=20
> [..]
>=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.
>=20
> SSL/TLS provides end-to-end security. It catches DNS forgery. It=20
> catches route hijacking. It catches an arbitrary man in the middle.=20
> If SSL/TLS is working, every security compromise that DNSSEC can=20
> prevent has already been covered, and then some.
I guess what this quote means is that two-way authenticated sessions, ie
client and server *remember* each others public keys, don't need any
third party to recognize them at later connections. The problem is to
authenticate if you only know a domain name.
>=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.
Not at all a waste. I think, it is the next best thing since sliced bread=
=2E
DNSSEC specifies the *intent* of the domain owner. A validated lookup
tells you which of the 160 CAs is the chosen one. It's the domain
owners' responsibility to run a monitoring script to detect rogue
DNS-registrars that send out wrong data, and publicly sentence those to
the internet death penalty.
If you don't trust your chosen CA, ie, it might be coerced to sign a
fake cert by an 'authority', create your own Root Key (on a smart card)
and use that for your server certificate.
The thing that is important is that the browsers must NOT look at the
'trusted' CA-list anymore!
Guido.
------enig2ENPJDICGQMIQUQMPFXVN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJSd3OiAAoJEHPd8GglaNRmZkwP/R686G6AZbA+dPwN9v7/+0zl
r7e48yo9IoWJer6XQLuDdskuftXCHjjfxM+4GFwowWuwAyG/a4CXN37CuTwAi+X3
X1idUd5UTZvA2GqiawelGz4mBzUiAvvqblN0bC3nfCgLTfTgAE1SITYI/tFPhyQN
aHjjdszuqH6MqcxZwwpTYPH5GeM5nYQxthW1wLwy5HtlW0EYyMFC+Xlk/Ra0NCDL
iBPy/e7jQqJ3bQ9mSz+4H6vmOWfrwmiDzKb0gj5gBxOtztNWn+8MVB21LQJqunX8
tgYYHN28xZXbB28nj9IITrnoA09mWF217pzMyxCCo8rYh2v1IKFOPIv/vn/uBynp
TBhTRoXBAn5PLFbzEiMx8u8o3CeF4aw20Pr30liUdaKAunMLmXWe6S9ybyrsZdvf
To8aU9G8VNXvqC9CjadWswwX0AHblSDc/5dukblmlJKwDl44tqBcscQ5NqzzseDX
qkzpE1I0XDnLkvmzWEY0iQ3Vvz43Nj2BbHozqxZGbtFrHVQTL3SJZ5eWZeLCG0Zb
Up8/Jk5a/YJpGxRbFRNFoVoxXnearvjHr6V91bdzzb/NZoK1vBAo4cpJ7GZDy3Pz
OKhB5VMRyOGkp09YmaGnSPj66nhmd49ERQHbW2hbsCdagrQBCet/BXs6UvhrxHCO
lqqgwxMauUwBHzkRIuM1
=dttP
-----END PGP SIGNATURE-----
------enig2ENPJDICGQMIQUQMPFXVN--
--===============5370828958863567797==
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
--===============5370828958863567797==--
