[e2e] TCP improved closing strategies?

[David P. Reed]

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.

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.

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.

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.

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

Perhaps this doesn't matter in your world.  It matters in the *real* 
world, where I happen to live.





On 08/18/2009 07:08 PM, William Allen Simpson wrote:
> David P. Reed wrote:
>> On 08/18/2009 12:56 PM, William Allen Simpson wrote:
>>> 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.
>>>
>> 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?
>>
> RTFM.
>
> At the risk of alienating the others on the list by replying to this
> drivel, I'm also looking forward to the magic wand that instantaneously
> replaces DNS with another protocol and infrastructure.
>
> Moreover, folks that don't top post in multipart/alternative text/html,
> expecting others to do the work of fixing their formatting for 
> readability.
>
> The thing that makes some of us more expert in security than others is 
> the
> day to day experience of securing the "grand practical scheme of things."
>
> And the willingness to openly ask questions instead of hurling 
> insults....
>
>
>>> 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).
>>>
>> 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?
>>
> We've all had that experience.  Some of us even *predicted* it long ago
> (late NSFnet/early commercial Internet days).  One of us even designed a
> secure ARP replacement, and proposed a shared-secret requirement for 
> DHCP,
> with a requirement that every Internet end-to-end session be secured for
> authentication, confidentiality, and integrity.
>
> Other folks argued against it.  The very idea that every system required
> at least 1 configured secret before installation was considered anathema.
> What about a thousand systems on the loading dock?  One fine fellow had
> the unmitigated gall to state (paraphrased) the ethernet model works fine
> today, why change it....
>
> I kept the recording for many years, as that person was forcibly made my
> "co-author" on Neighbor Discovery, who then removed all the security and
> hidden terminal (for wireless) discovery.  Only now are they adding that
> back again (badly and inelegantly).  Better late than never?
>
> N.B.: now ATT 2-wire cable boxes actually come pre-configured with a
> secret, printed right on the label.  Finally!  If only it was a UPC, so
> those could easily be scanned into a database for a thousand boxes on the
> loading dock....
>
>
>> 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.
>>
> Employing?  You're being paid for this diatribe?
>
> Where were you during the crypto-wars?  Where was *your* running code?
>
> Who was it that specified only 65K UDP ports?  Who didn't randomize the
> Source port to prevent prediction, resulting in DNS cache poisoning?
> Who didn't even think about security for the Internet as a whole?
>
> (Compartment options are not security, they're bureaucracy.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090819/80a07cec/attachment-0001.html