Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05

Paul Hoffman <phoffman@imc.org> Fri, 08 January 2010 18:37 UTC

Return-Path: <phoffman@imc.org>
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 58CC13A68A6 for <secdir@core3.amsl.com>; Fri, 8 Jan 2010 10:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 3RgV4IwsSqF4 for <secdir@core3.amsl.com>; Fri, 8 Jan 2010 10:37:00 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 844A13A688C for <secdir@ietf.org>; Fri, 8 Jan 2010 10:37:00 -0800 (PST)
Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o08Iana9028426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 11:36:50 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240824c76d2b183957@[10.20.30.158]>
In-Reply-To: <20100108182219.GN26259@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]> <20100108182219.GN26259@shinkuro.com>
Date: Fri, 8 Jan 2010 10:36:48 -0800
To: Andrew Sullivan <ajs@shinkuro.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: secdir@ietf.org, dol@cryptocom.ru, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
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: Fri, 08 Jan 2010 18:37:01 -0000

At 1:22 PM -0500 1/8/10, Andrew Sullivan wrote:
>On Fri, Jan 08, 2010 at 08:12:29AM -0800, Paul Hoffman wrote:
>
>> It is for this reason that DNSSEC does not, for example, require
>> that resolvers MUST be able to validate RSA signatures with 256-bit
>> keys. However, by saying that resolvers MUST be able to validate
>> anything other than the widely-agreed-to algorithms, you are opening
>> up such an attack.
>
>Now, this is an interesting point.

Thank you. However, it is far from original.

>I think if one combines this
>argument with Steve's point that a certain baseline of mandatory
>algorithms should be required _only_ because you need some common set
>for interoperability, one has a pretty good argument that most
>algorithms should be MAYs and not stronger.

Bingo. If there is an algorithm that the technical community thinks is the "next" mandatory algorithm, you might want to make it "SHOULD+", but even that proposal is not always clear-cut.

<cue the peanut gallery>