[e2e] TCP improved closing strategies?

[David P. Reed]

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".

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?

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 www.google.com 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?

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.




On 08/18/2009 12:56 PM, William Allen Simpson wrote:
> David P. Reed wrote:
>> On 08/18/2009 11:42 AM, Joe Touch wrote:
>>> It means you didn't need TCP.
>> Exactly!
>>> You can't flush TCP state unless you know
>>> you don't need what it provides - notably protection that the next TCP
>>> connection on that socket pair won't be affected by late arriving
>>> segments from the previous connection.
>>>
>>> Let's not change TCP semantics in this regard; let's just not use TCP
>>> where TCP semantics aren't needed.
>> 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.
>>
> Thank you to everybody that provided substantive information and 
> pointers.
>
> I look forward to David's information theoretic cryptology that crams 
> SOA,
> several NS, and a half dozen digital signatures into 512 bytes over UDP,
> for the simplest secure case of NXDOMAIN.
>
> With several hundred thousand clients per minute using 65,000 ports.
> Through NAT boxen that pass *only* TCP and UDP, and don't randomize the
> Source port, and don't properly handle returning IP fragments.  Etc.
>
> Back in the real world, that means TCP semantics, such as retransmission
> of lost segments.
>
> Or reinventing the wheel (segmentation and retransmission over UDP).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090818/16887013/attachment.html