Re: [Asrg] DNS over SCTP

Alessandro Vesely <vesely@tana.it> Thu, 28 May 2009 15:51 UTC

Return-Path: <vesely@tana.it>
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 5B37C3A6FCD for <asrg@core3.amsl.com>; Thu, 28 May 2009 08:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Level:
X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 wCEy59xEls8x for <asrg@core3.amsl.com>; Thu, 28 May 2009 08:51:57 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id B1A673A6C2E for <asrg@irtf.org>; Thu, 28 May 2009 08:51:03 -0700 (PDT)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Thu, 28 May 2009 17:47:12 +0200 id 00000000005DC02F.000000004A1EB200.00004987
Message-ID: <4A1EB214.6090507@tana.it>
Date: Thu, 28 May 2009 17:47:32 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
References: <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> <4A1E8BD3.8000103@tana.it> <20090528131509.GA13521@nic.fr> <4A1E9CBF.4010703@tana.it> <20090528142325.GA22943@nic.fr>
In-Reply-To: <20090528142325.GA22943@nic.fr>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Anti-Spam Research Group - IRTF <asrg@irtf.org>, ietf@ietf.org
Subject: Re: [Asrg] DNS over SCTP
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: Thu, 28 May 2009 15:51:57 -0000

Stephane Bortzmeyer wrote:
> On Thu, May 28, 2009 at 04:16:31PM +0200,
>  Alessandro Vesely <vesely@tana.it> wrote 
>  a message of 14 lines which said:
> 
>> The discussion was about how to get rid of the threats illustrated,  
>> e.g., in Kaminsky, D.: "It?s the end of the cache as we know it." 
> 
> I know about Kaminsky bug, the WG "DNS operations" and "DNS
> extensions" spent a lot of time on it. Please do not restate the
> basics and explain why SCTP (or TCP) can be compared with DNSSEC
> since, as I said, DNSSEC provides *object* security and TCP (or SCTP)
> can only provide a limited *channel* security.

I don't trust the data because it is signed, I trust it because the 
signature proves that it originated from the authoritative server. 
Therefore, if I'm connected with the authoritative server over a 
trusted channel, I can trust the data even if it isn't signed. By 
induction, if a resolver only uses either signed data or trusted 
channels, I can trust it.

After all, cryptography just provides trusted channels of their own 
kind. The comparison involves the security features of those two kinds 
of channels.

The limitations in TCP or SCTP security stem from an attacker's 
ability to compromise one or more routers, so as to either tamper with 
the packets on the fly, or redirect them to some other host. That's 
much more difficult than forging the source address of an UDP packet, 
though.