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

Barry Leiba <barryleiba@computer.org> Tue, 02 March 2010 20:42 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 E925E28C144; Tue, 2 Mar 2010 12:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 pGQDzr+DmGq8; Tue, 2 Mar 2010 12:42:28 -0800 (PST)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id B100B28C0CF; Tue, 2 Mar 2010 12:42:27 -0800 (PST)
Received: by fxm5 with SMTP id 5so757089fxm.29 for <multiple recipients>; Tue, 02 Mar 2010 12:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=JRdR4QFA9z7fTUvqhaT1UYCF+4s3AUkJ9wNRE28xtr8=; b=ConQN71v9QXsxkezb55/z/BrYUdGlpfzIIllWk0Oy0SZc4GcLIsDfgzwKoSlrK4pTu kJVZNtvg5ftPTGtlrxv0wY544BN2m3PM1zqZaZw4yBkNysLRNJL4QsfA7rH2vQ+gA34M BqcpIumKuQHdg5xkgfmRzIY3cp+hNDkICnMx4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wZtIuys0zidorfMCw+Yxaa+2wc/JdkpXkS5nL7ZChQF+d4RBKQ3drOSqb7jszaSpTq SAciJGS5frqbMSS4a/Jvpa6WmnMs/UNRVdVQ++o535EMKulJY1n8B/fPKgPElN6y8hMB YH21+ifDSBkeXb3VDdseucZkkZ9kAS6aMsNzw=
MIME-Version: 1.0
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.223.14.15 with SMTP id e15mr7270850faa.57.1267562545046; Tue, 02 Mar 2010 12:42:25 -0800 (PST)
In-Reply-To: <20100302203103.GJ2901@shinkuro.com>
References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com>
Date: Tue, 2 Mar 2010 15:42:24 -0500
X-Google-Sender-Auth: 02d3c9e5e7c2eaf0
Message-ID: <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Andrew Sullivan <ajs@shinkuro.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 20:42:29 -0000

> The upshot therefore of your suggestion is that the expert review
> required in this area would probably require an expert panel in each
> case, with one member from the DNS community and another from the
> security community.

I understand.

> 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.

> 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.

Anyway, repeating: my lone opinion on this doesn't override a bunch of
people who spent a lot of time going over this and came to consensus.
I'm just a bit concerned, is all.

Barry