<!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">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.</font> 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>
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>
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>
<br>
<br>
<br>
On 08/18/2009 12:56 PM, William Allen Simpson wrote:
<blockquote cite="mid:4A8ADD53.2010107@gmail.com" type="cite">David P.
Reed wrote:
<br>
<blockquote type="cite">On 08/18/2009 11:42 AM, Joe Touch wrote:
<br>
<blockquote type="cite">It means you didn't need TCP.
<br>
</blockquote>
Exactly!
<br>
<blockquote type="cite">You can't flush TCP state unless you know
<br>
you don't need what it provides - notably protection that the next TCP
<br>
connection on that socket pair won't be affected by late arriving
<br>
segments from the previous connection.
<br>
<br>
Let's not change TCP semantics in this regard; let's just not use TCP
<br>
where TCP semantics aren't needed.
<br>
</blockquote>
If you recall, that was my original point, in my original response.
DNS shouldn't use TCP just because some DNS technique gets expansive
enough to sometimes require more than 1 IP datagram. As I originally
suggested, simple information theoretic analysis suggests that one can
do the DNS request/response within one UDP datagram each way, so my
suggestion in this case is to send the DNS layer protocol designer
back to the drawing board with an information theorist and
cryptographer at his/her elbow.
<br>
<br>
</blockquote>
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>
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>
</body>
</html>