Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02

Andrew Sullivan <ajs@shinkuro.com> Tue, 02 March 2010 23:12 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E905F28C2A7; Tue, 2 Mar 2010 15:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599]
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 1Ir74c8ugzR4; Tue, 2 Mar 2010 15:12:16 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A6FED28C25C; Tue, 2 Mar 2010 15:12:12 -0800 (PST)
Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EE1ED1ECBC22; Tue, 2 Mar 2010 23:12:10 +0000 (UTC)
Date: Tue, 2 Mar 2010 18:12:04 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Barry Leiba <barryleiba@computer.org>
Message-ID: <20100302231204.GM2901@shinkuro.com>
References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 23:12:23 -0000

On Tue, Mar 02, 2010 at 03:42:24PM -0500, Barry Leiba wrote:
> > More importantly, I'm not sure there's actually a problem to solve
> > here.  Do we have a problem in other protocols where poor crypto
> > algorithms have won out over better-designed algorithms?
> 
> Actually, we do -- not with "won out", so much as "got implemented",
> which then leaves a hole in the algorithm negotiation process.  HTTP
> clients and servers, for instance, often support long-broken versions
> of SSL, weak encryption algorithms, and too-short key lengths.  The
> result is that both clients and servers can be steered, in the
> negotiation process, toward use of weak crypto, which can then
> undermine the security of the transactions.

Hrm.  Well, in DNSSEC, there _is_ no algorithm negotiation process.
The client validates using the signatures that are published, or it
doesn't validate at all.  And remember that in the case of DNSSEC, we
have no reason (so far) to suppose that we'll get to the state where
validation is required.  Under the protocol, if you don't understand
the algorithm on the signature available to you (which could actually
be a subset of the signatures in the zone, due to the effects of
caches), you just treat the response as not secured.  So it's just
like the zone isn't signed. 

There's the additional factor that adding algorithms increases
response size, which increases transit cost for the zone operator.

Because there's no way to negotiate the algorithm and there's an
incentive to keep the number of algorithms in use small, we've had the
idea that validators are likely to converge on one or two good ones,
and tend to stay there.
 
> > We do in fact have a completely separate effort underway to update the
> > registry in order to allow certain kinds of indicators like this.  The
> > WG seemed to agree that these were separate problems and didn't want
> > to conflate them.  Does that other effort address your concern?
> 
> Partially.  It depends upon how that work resolves the question of who
> gets to decide what values those indicators take.  If I can register
> the BBC algorithm (Barry's Broken Crypto), and give it soi-disant
> "highly recommended" status, then nothing's solved.  If someone *else*
> is responsible for controlling that field, then we're back to asking
> who the expert (or panel of) is.

The text of this draft currently explicitly notes that it doesn't
change the rules for making an algorithm mandatory to implement.
Since making an algorithm mandatory to implement would update 4034, I
therefore think that it would still require standards action, which
punts the whole business right back to the same process in place
today.  Does that make you less uneasy?

Best,

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.