Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review

Douglas Otis <dotis@mail-abuse.org> Fri, 29 May 2009 23:22 UTC

Return-Path: <dotis@mail-abuse.org>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34133A6C9C for <asrg@core3.amsl.com>; Fri, 29 May 2009 16:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.338
X-Spam-Level:
X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1bw-3sbqQxF for <asrg@core3.amsl.com>; Fri, 29 May 2009 16:22:39 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id C74D73A6B7B for <asrg@irtf.org>; Fri, 29 May 2009 16:22:39 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 1662EA9443F; Fri, 29 May 2009 23:24:22 +0000 (UTC)
Message-Id: <892F581E-BCE7-48D2-B6C3-429F56B3A3F5@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <87d49rraqd.fsf@mid.deneb.enyo.de>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 29 May 2009 16:24:21 -0700
References: <003d01c9dd01$bf3531d0$800c6f0a@china.huawei.com> <4A1A45BA.5030704@swin.edu.au> <3be421270905250718y5d62f6d5odb6f2bebecf418d0@mail.gmail.com> <6684E747-55CB-4BB3-B838-9F4FE906AFE7@mail-abuse.org> <200905251603.MAA16221@Sparkle.Rodents-Montreal.ORG> <CCE0A3E1-4BCB-460C-AEA0-6548BB4AE8FE@mail-abuse.org> <4A1D64C9.5060505@tana.it> <47BC2197-472E-4615-97D2-F7E42B8F3B7D@mail-abuse.org> <87d49rraqd.fsf@mid.deneb.enyo.de>
X-Mailer: Apple Mail (2.935.3)
Cc: asrg@ietf.org
Subject: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 23:22:40 -0000

On May 29, 2009, at 12:05 PM, Florian Weimer wrote:

> * Douglas Otis:
>
>>> Just using TCP would prevent most of the DNS poisoning attacks  
>>> that Amir's paper reports.
>>
>> TCP is prone to DDoS attack.
>
> Only when implemented naively.  If the client does not split the  
> query into two packets or artificially lowers the window size, you  
> can answer it without creating any state.

Any modification to TCP that bypasses SYN/ACK handshakes for full- 
duplex data is not TCP.  Indeed, DNS could operate accepting any TCP  
packet "as-if" SYN-ACK handshakes occurred. The stack could initially  
ignore sequence numbers, and assume all DNS messages are fully  
contained within the packet, and that all messages are always frame  
aligned.

This approach omits source verification, and therefore is unable to  
mitigate spoofed reflected attacks.  The same effect could be achieved  
using EDNS0 options that extend both transaction-ids as well as packet  
size.  Of course, discovering whether a DNS server violates TCP  
protocols or implements a new EDNS0 option may also expend an  
additional exchange.  This initial exchange would determine whether  
the DNS server uses a facocta TCP or chokes on a new EDNS0 option.  Of  
course, the originating DNS client will need to retain this result to  
establish global state to avoid increased resource consumption.  The  
initial exchange would also determine whether MTU limitations or  
packet inspection on the path may also cause non-compliant packets to  
be dropped.  Any attack hammering the client may therefore induce the  
downgrading to less secure modes.

> The argument against TCP is not the protocol.  It's just that you  
> have to upgrade both authoritative servers and resolvers to make it  
> work well.

Huh? Why suggest radical changes to the TCP protocol, and then, in the  
same breath, say the problem is not the protocol?

Defending against DDoS attack was never a major consideration during  
early TCP or UDP development.  Bot-nets weren't the problem they are  
today.  Bastardizing TCP, rather than adopting properly designed  
protocols, is unlikely to provide a solutions, but instead likely to  
create new vulnerabilities.

-Doug