<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">Since you persist in being a
jerk, Mr. Simpson, I suggest you ask someone who actually was involved
what role I played in the "crypto wars" (a small one, but an important
one, I think, which legitimized public key crypto in the broad public
market), and what role I played in attempting to get TCP (the original
version) made cryptographically secure from the beginning when I was
working to try to get Steve Kent's work into the original standard,
despite NSA opposition.<br>
<br>
Yes, I speak flamboyantly sometimes. Sometimes I need to apologize as
a result. That is needed to cut through the crap spewed as arguments
that are grounded in the notion that security is about "patching"
against the last attack, or grounded in the idea that protocol design
is about byte ordering and understanding the difference between MUST
and SHOULD.<br>
<br>
Your insults miss the mark, because they are wrong. I'm happy to
apologize if you feel personally insulted. However, the situation that
concerns me remains: this whole project of "securing DNS" is a pile of
bad designs aimed at a narrow script-kiddie threat, while opening up a
window for far greater attacks (DDOS, etc.) and leaving the barn door
open to a wide variety of problems, both security problems and
authority problems.<br>
<br>
A real, pragmatic security expert would realize the security 101 is: if
you strengthen A, but leave B weak, the attackers will move to B. If
you strengthen A against one attack, but but leave problems unaddressed
that create a set of new attacks in the process, you actually make the
problem worse, not better.<br>
<br>
The best solution for security starts with an "end-to-end"
understanding of the fundamental function you are trying to provide,
and its security requirements. Typically "optimizations" introduced in
*security* situations have the property of not fully solving the
problem, but even worse, introducing new problems (hence the
introduction of TCP statefulness into a DNS adds the potential of
attacks through state disruption, and the introduction of
kernel-implemented TCPs with a wide variety of quirks introduces far
more attacks through kernel-access paths).<br>
<br>
Perhaps this doesn't matter in your world. It matters in the *real*
world, where I happen to live.<br>
<br>
<br>
<br>
<br>
</font><br>
On 08/18/2009 07:08 PM, William Allen Simpson wrote:
<blockquote cite="mid:4A8B3468.2060608@gmail.com" type="cite">David P.
Reed wrote:
<br>
<blockquote type="cite">On 08/18/2009 12:56 PM, William Allen Simpson
wrote:
<br>
<blockquote type="cite">Thank you to everybody that provided
substantive information and pointers.
<br>
<br>
I look forward to David's information theoretic cryptology that crams
SOA,
<br>
several NS, and a half dozen digital signatures into 512 bytes over
UDP,
<br>
for the simplest secure case of NXDOMAIN.
<br>
<br>
</blockquote>
I'd suggest that identity based encryption would provide a good
starting point the level of quote-security-endquote that is needed for
DNS in the grand practical scheme of things. But I'd probably be
accused of being unconnected with the simple reality of people who
thing that SOA/certificates/etc. being mumbled makes one an expert on
"security".
<br>
<br>
What is the risk and what is the threat model, in one simple statement
that doesn't involve claims that DNS is somehow a "super secure" system
to start with?
<br>
<br>
</blockquote>
RTFM.
<br>
<br>
At the risk of alienating the others on the list by replying to this
<br>
drivel, I'm also looking forward to the magic wand that instantaneously
<br>
replaces DNS with another protocol and infrastructure.
<br>
<br>
Moreover, folks that don't top post in multipart/alternative text/html,
<br>
expecting others to do the work of fixing their formatting for
readability.
<br>
<br>
The thing that makes some of us more expert in security than others is
the
<br>
day to day experience of securing the "grand practical scheme of
things."
<br>
<br>
And the willingness to openly ask questions instead of hurling
insults....
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">With several hundred thousand clients per
minute using 65,000 ports.
<br>
Through NAT boxen that pass *only* TCP and UDP, and don't randomize the
<br>
Source port, and don't properly handle returning IP fragments. Etc.
<br>
<br>
Back in the real world, that means TCP semantics, such as
retransmission
<br>
of lost segments.
<br>
<br>
Or reinventing the wheel (segmentation and retransmission over UDP).
<br>
<br>
</blockquote>
In a world where I check into a hotel that forcibly rapes my packets
starting with the ARP packets and going up through DHCP, so that when I
send a TCP/IP packet to <a class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a> on port 80 it gets redirected to
a server that opendns.com (the world's "safest" DNS service) has been
told is to handle all google traffic (no NXDOMAIN here) which scrapes
my requests in order to sell my personal interests to a marketing
company?
<br>
<br>
</blockquote>
We've all had that experience. Some of us even *predicted* it long ago
<br>
(late NSFnet/early commercial Internet days). One of us even designed
a
<br>
secure ARP replacement, and proposed a shared-secret requirement for
DHCP,
<br>
with a requirement that every Internet end-to-end session be secured
for
<br>
authentication, confidentiality, and integrity.
<br>
<br>
Other folks argued against it. The very idea that every system
required
<br>
at least 1 configured secret before installation was considered
anathema.
<br>
What about a thousand systems on the loading dock? One fine fellow had
<br>
the unmitigated gall to state (paraphrased) the ethernet model works
fine
<br>
today, why change it....
<br>
<br>
I kept the recording for many years, as that person was forcibly made
my
<br>
"co-author" on Neighbor Discovery, who then removed all the security
and
<br>
hidden terminal (for wireless) discovery. Only now are they adding
that
<br>
back again (badly and inelegantly). Better late than never?
<br>
<br>
N.B.: now ATT 2-wire cable boxes actually come pre-configured with a
<br>
secret, printed right on the label. Finally! If only it was a UPC, so
<br>
those could easily be scanned into a database for a thousand boxes on
the
<br>
loading dock....
<br>
<br>
<br>
<blockquote type="cite">Get real. Security used to mean something
other than employing security consultants to work on subproblems as if
they were the fundamental issue, and crap up fundamentally weak systems
with bells-and-whistles like TCP magic close protocols that only add
DDOS attack risks, while fixing nothing important.
<br>
<br>
</blockquote>
Employing? You're being paid for this diatribe?
<br>
<br>
Where were you during the crypto-wars? Where was *your* running code?
<br>
<br>
Who was it that specified only 65K UDP ports? Who didn't randomize the
<br>
Source port to prevent prediction, resulting in DNS cache poisoning?
<br>
Who didn't even think about security for the Internet as a whole?
<br>
<br>
(Compartment options are not security, they're bureaucracy.)
<br>
<br>
</blockquote>
</body>
</html>