Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

"Steven M. Bellovin" <smb@cs.columbia.edu> Wed, 24 February 2010 19:27 UTC

Return-Path: <smb@cs.columbia.edu>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9313A8575 for <ietf@core3.amsl.com>; Wed, 24 Feb 2010 11:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4tvTkMFj1ytR for <ietf@core3.amsl.com>; Wed, 24 Feb 2010 11:27:26 -0800 (PST)
Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 36A463A8571 for <ietf@ietf.org>; Wed, 24 Feb 2010 11:27:26 -0800 (PST)
Received: by machshav.com (Postfix, from userid 512) id 765A652D5E8; Wed, 24 Feb 2010 14:29:35 -0500 (EST)
Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9D2F552D4ED; Wed, 24 Feb 2010 14:29:33 -0500 (EST)
Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 1252F293DA1; Wed, 24 Feb 2010 14:29:27 -0500 (EST)
Date: Wed, 24 Feb 2010 14:29:26 -0500
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
Message-ID: <20100224142926.21d929c0@yellowstone.machshav.com>
In-Reply-To: <a123a5d61002240944l3944a8acy804a1d819bf2cc3d@mail.gmail.com>
References: <874c02a21002231826y613b9f97ya83740ba240f7bf9@mail.gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D02C29D87@GLKMS2100.GREENLNK.NET> <sdzl2yvgru.fsf@wjh.hardakers.net> <874c02a21002240835u7cf4bf60y510cbbc870727852@mail.gmail.com> <20100224165011.GF5166@thunk.org> <a123a5d61002240944l3944a8acy804a1d819bf2cc3d@mail.gmail.com>
Organization: Columbia University
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64--netbsd)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>, tytso@mit.edu, ietf@ietf.org, Wes Hardaker <wjhns1@hardakers.net>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2010 19:27:27 -0000

On Wed, 24 Feb 2010 12:44:10 -0500
Phillip Hallam-Baker <hallam@gmail.com> wrote:

> The problem here is not that you might infringe the patent, the
> problem is that if a patent suit is brought against you, it will cost
> a minimum of about $5 million to defend. Just to get to the point of
> having an opinion on the matter you would have to engage a competent
> expert witness who was willing to work on patent stuff rather than
> building stuff. Then they have to do maybe a months work on research
> and explain the results to a group of lawyers. You are going to have
> five or more people and rack up several thousand hours at lawyer
> rates.
> 
> Those costs buy a lot of crypto accelerator boards.
> 
> I kept trying to explain this situation to the various people who
> tried to sell their 'efficient CRL' hacks. Even if your system is the
> greatest ever and you give it to me for free, it will cost more to
> work out if it is legally safe than it costs to solve the problem with
> raw CPU power.
> 
> 
> If the 512 byte limit really is a problem, then the logical answer
> would be to use DSA-SHA256 since the signatures generated in DSA are
> not a function of the key size. DSA also allows for offline
> calculation of the signature data which would address performance
> issues for companies like Akamai.
> 
> There are also reasons to beware of DSA. Steve Bellovin pointed out
> that if the random number generator is bad the private key can leak
> out. But RSA is not without similar issues, companies that can't
> generate a good random seed for DSA will probably not create secure
> keypairs for RSA either.
> 
I've pointed it out in the IETF, but I'm certainly not the one who came
up with that observation in the first place; please do not give me
credit for other folks' work.

More on-topic: unless I'm very much mistaken, DNScurve relies on
transmission security rather than object security; in turn, that
requires a pretty fundamental change in how the DNS works.  (Well, not
completely, but you wouldn't gain any security benefit against most of
the threats from cache contamination if you didn't change it.)  Maybe
the DNS can work that way or should work that way -- but I haven't seen
any analysis to show that the load is manageable without caching and
with lots of banging on the authoritative servers.