Re: [Asrg] DNS over SCTP

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 29 May 2009 05:13 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 DB1D73A6DE2 for <asrg@core3.amsl.com>; Thu, 28 May 2009 22:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.15
X-Spam-Level: **
X-Spam-Status: No, score=2.15 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_NJABL_PROXY=1.643]
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 UsgTRbG-LVRh for <asrg@core3.amsl.com>; Thu, 28 May 2009 22:13:43 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 383D23A6DB9 for <asrg@irtf.org>; Thu, 28 May 2009 22:13:43 -0700 (PDT)
Received: (qmail 73224 invoked from network); 29 May 2009 06:44:24 -0000
Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 29 May 2009 06:44:24 -0000
Message-ID: <4A1F6F38.7010602@necom830.hpcl.titech.ac.jp>
Date: Fri, 29 May 2009 14:14:32 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Douglas Otis <dotis@mail-abuse.org>
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> <4A1EB214.6090507@tana.it> <1E0EDA86-CFF5-40AC-AEE8-E943317E1E3C@virtualized.org> <85FC4673-7256-4372-B4DD-260A3F8AEDA9@mail-abuse.org>
In-Reply-To: <85FC4673-7256-4372-B4DD-260A3F8AEDA9@mail-abuse.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 30 May 2009 16:32:53 -0700
Cc: Anti-Spam Research Group - IRTF <asrg@irtf.org>, David Conrad <drc@virtualized.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: Fri, 29 May 2009 05:13:44 -0000

Douglas Otis wrote:
    
> While DNSSEC may protect against data corruption,

So does TCP, UDP or SCTP checksum.

A problem is that such protection does not valid over a chain of
certificate authorities or caching servers.

> such protection  
> depends upon the thorny problem of verifying a key will be solved in a  
> practical and politically acceptable manner.

If the protection by a chain of untrustworthy certificate authorities
of DNSSEC is practically acceptable, a protection by a chain of
untrustworthy caching servers of plain old DNS is also practically
acceptable. Moreover, plain old DNS is already practically accepted.

Though there seems to be some confusion that DNSSEC security were
end to end, below is an excerpt from an authentic document by David
Clark on how PKI, including DNSSEC, involves certificate authorities
of third parties.

http://portal.acm.org/citation.cfm?doid=383034.383037
Public-key certificates
An important role for a third party occurs when public key cryptography
is used for user authentication and protected communication. A user can
create a public key and give it to others, to enable communication with
that user in a protected manner. Transactions based on a wellknown
public key can be rather simple two-party interactions that fit well
within the end to end paradigm. However, there is a key role for a
third party, which is to issue a Public Key Certificate and manage the
stock of such certificates; such parties are called certificate
authorities. The certificate is an assertion by that (presumably
trustworthy) third party that the indicated public key actually goes
with the particular user.


So, though communication between an end user and a certificate
authority can be end to end, the entire system of PKI is not.

							Masataka Ohta