[Cryptography] Preliminary review of the other Applied Cryptography

[David Conrad]

On Apr 9, 2014, at 12:46 PM, tpb-crypto at laposte.net wrote:
> Most of us can relate with that, the "SEC" in DNSSEC is kind of misleading to put it mildly. Of "SEC", DNSSEC has nothing.

Oh, sure it does.

> People were expecting some form of encryption to the standard when it was first announced and after a so long wait it came out still working in plaintext and worse, forcing people to expose their infrastructure to use it.

If you're talking about zone walking, that was addressed with NSEC3. 

> What is the SEC in that really? SECurely allowing yourself to be snooped and spoofed? SECure to whom?

DNSSEC was designed to address the vulnerability caused by a limited (16-bit) identifier space in the original DNS protocol specification, nothing more.  In that, I would argue DNSSEC does a reasonable job -- it ensures that data provided by the authoritative server hasn't been modified in flight to the validating resolver.  As far as I know, no one ever claimed or even suggested it would provide confidentiality.  However, if you have a validating resolver and a properly configured trust anchor and are requesting data from a signed zone (> 50% of the top-level domains are now DNSSEC-signed), you are not subject to spoofing attacks as the validator will drop spoofed responses.

> Maybe some lover of this standard can come forward to its defense.

While I'm generally not considered a 'lover' of DNSSEC (to put it mildly), I do think it is less offensive than the alternative of not having authenticatable responses (regardless of the transport of those responses). More interestingly, DNSSEC can potentially provide a basis for an alternative PKI to the X.509 PKI. I personally would see that as a positive.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140409/d074e866/attachment.pgp>