AS IF: draft-ietf-dnsext-ad-is-secure-03.txt

[John Gilmore <[e-mail]>]

I think some of you guys have gotten so tied up in micromanaging DNS
Security implementation details that you forgot what swamp we were
trying to drain.

There is no point in building a cryptographically-secured DNS in which
many of the machines will be configured to "just believe whatever they
are told, regardless of the cryptographic signatures"!

We already have such a DNS -- today's.  It doesn't need signatures or
AD bits or big packets or any other changes.  Anyone who is happy
with that can go home and stop arguing.  The rest of us are interested
in the real security and integrity of the Internet.

Any client implementation that listens to a single bit of the response
to tell it whether the response is cryptographically valid must be
considered noncompliant with the DNSSEC spec.  It's just an old
fashioned insecure DNS client.  There's nothing wrong with that, as
long as you don't have any high trust expecations for it.

Any server which deposits a single bit in the response to claim to
clients that it has cryptographically validated the results, so
they don't have to, is just encouraging the above abuse.

I'm not shocked to find people advocating that such a server actually
lie to the clients about whether it has validated the data.  The
entire model (trusting a packet to tell you whether somebody else has
validated the data) provides ample opportunities for not only your
friends but your enemies to lie to you.  Just like in the current DNS.

	John

PS: I know, I know, the "valid" bit will be secured by some "out of
band" means.  Like a shared static key, and/or by the security of the
file system on the server.  Right.  For extra credit: composing
several weak security primitives produces what?  Strong security or
weak security?

PPS: The real question is why anyone is advocating that the DNS be
"secured" by lame security.  There are challenges aplenty even when
you're working with strong primitives; trying to mix in weak stuff is
just wasting everyone's time.  People have encouraged me in the past
to assume the possibility of mere incompetence rather than assuming
actual malice (e.g. when the FBI's Louis Freeh testified to Congress
about the security of DES).  So: Were any of you on the standards
committees for cellphone privacy?  How about on the 802.11 "Wiretap
Equivalent Privacy" committee?  Did any of you have a hand in
shortening the key in DES?  Perhaps you designed the encryption scheme
used in DVDs or in Adobe eBooks?  Whether you're incompetent or
malicious, stick to breaking codes, it's much easier.  Especially when
you break them in the standards committee before they're deployed.


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.