[148028] in cryptography@c2.net mail archive
Re: [Cryptography] DNSSEC = completely unnecessary?
daemon@ATHENA.MIT.EDU (Greg)
Tue Nov 5 12:31:24 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
In-Reply-To: <20131105015705.980ADE9F3@a-pb-sasl-quonix.pobox.com>
Date: Tue, 5 Nov 2013 11:47:55 -0500
To: Bill Stewart <bill.stewart@pobox.com>
Cc: "cryptography@metzdowd.com List" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3803487443299415940==
Content-Type: multipart/signed; boundary="Apple-Mail=_ABE0CC4B-E134-4479-B1DC-1E96789DB1CF"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_ABE0CC4B-E134-4479-B1DC-1E96789DB1CF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Nov 4, 2013, at 8:48 PM, Bill Stewart <bill.stewart@pobox.com> wrote:
> SSH isn't HTTPS. Nor are SFTP, SCP, etc.
These, I believe, are using the same exact mechanism (and often, keys) =
for enc + auth, correct?
IMO they do a better job at auth than HTTPS and DNSSEC, cause at least =
with SSH there's no list of CA's to trust. Much harder to MITM it than =
HTTPS.
> Outbound Email isn't HTTPS, even if it's sometimes TLS.
> Inbound SMTP often isn't even TLS, but sometimes you want to check =
where it came from.
> DNS isn't HTTPS, but sometimes you want to trust it, or if you're Dan =
Kaminsky you might want to tunnel ssh and video over it.
> NFS isn't HTTPS, and sometimes you want to use DNS with it.
> Printer protocols often aren't HTTPS.
[ .. ]
> DNSSEC doesn't protect you against exactly the same threats that =
SSL/TLS CAs do - it does a better job of confirming that you're talking =
to example.com when you think you are. Some CAs try to do a better job =
of telling you that example.com belongs to The Example Corporation, as =
opposed to examp1e.com (note the numeral "1") which belongs to Scammers =
Inc., but you've got to be good at restricting which CAs you believe.
OK, well, the solution isn't DNSSEC.
SMTP, DNS, NFS, printer protocols, et. al., need to be using encryption =
+ authentication, and not relying on a handful of CAs for it.
DNSSEC is not the answer to these problems.
DNSSEC is yet another giant problem to which the answer is the garbage =
can.
We need to get rid of CAs completely.
The idea of all-important authority figures to determine who is and is =
not trustworthy sounds like it's coming straight out of some sort of =
dystopian novel.
Yes, we need an _authority_, but we can do completely without authority =
figures (and be better off).
The "ultimate authority" should not be some random third party machine =
sitting in a basement in god knows where. If there is an "ultimate =
authority", it's the individual/printer themselves, and no one else.
And when they are unable to speak for themselves, it should be the =
network itself, and not one that's arranged in any sort of hierarchical =
fashion with a "head boss" holding "master keys" at the top.
- Greg
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
--Apple-Mail=_ABE0CC4B-E134-4479-B1DC-1E96789DB1CF
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
iQEcBAEBCgAGBQJSeSE/AAoJEKFrDougX6FkUtQH/05C0NZ+Pl01oE20Q2tMIOdy
0CgLSdom9bmaJAXW0I9gumttVkWLhpQWLkS0TixkkQfVocUt5PhbIX4smqmRi1rl
7VMOG9FVHm4vld6coh/KxwUUrRK/NCNEaedfTHoUcBV7r97tM4xs3ta72mKGTgue
W/L6MDWwImjXkGkMUGONMhGcJ5H1jhYEdwQCRCfEOQLvn4GgPY7uyKZcHO11y9Pt
pyhCckP/eOwbJ1gGVdL2opdOqipIPRTYhs8HT0hPY2vxljvibbnB+FbHCnPKKPiH
UedDpQuUe4fR2CsT/CfyknNHEJPD7UhfVsz3qYGM4KfRjPmF7Uw1aRVrJeW9LjQ=
=BQvS
-----END PGP SIGNATURE-----
--Apple-Mail=_ABE0CC4B-E134-4479-B1DC-1E96789DB1CF--
--===============3803487443299415940==
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
--===============3803487443299415940==--
