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

Andrew Sullivan <ajs@shinkuro.com> Thu, 07 January 2010 22:28 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 D121428C112 for <secdir@core3.amsl.com>; Thu, 7 Jan 2010 14:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 1966PLiipqZu for <secdir@core3.amsl.com>; Thu, 7 Jan 2010 14:28:17 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EDDB628C0E6 for <secdir@ietf.org>; Thu, 7 Jan 2010 14:28:16 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 646842FE8CA1; Thu, 7 Jan 2010 22:28:14 +0000 (UTC)
Date: Thu, 07 Jan 2010 17:28:09 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20100107222809.GA25747@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <p06240810c76be77be756@[128.89.89.161]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Ralph Droms <rdroms@cisco.com>, dol@cryptocom.ru, ogud@ogud.com, secdir@ietf.org
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: Thu, 07 Jan 2010 22:28:17 -0000

Hi,

I want to emphasise two things, before my question:

    1.  I'm not the shepherd for this document, but I'm asking this
    question in my capacity as co-Chair, such that I might ask
    something (or not ask) of document editors based on the response.

    2.  I super-really-I-mean-it don't have a strong opinion on this
    matter yet.

On Thu, Jan 07, 2010 at 02:38:14PM -0500, Stephen Kent wrote:

> Other IETF WGs (e.g., IPsec, S/MIME, OPGP, and TLS) have adopted a  
> policy of publishing RFCs that describe how to use one or more national 
> algorithms in the context of a protocol. However, in these WGs, support 
> for the algorithm is optional, i.e., a MAY in RFC 2119 parlance. These 
> RFCs define how to use a national algorithm IF one chooses to implement 
> it. They do not require support for the algorithm by making it a SHOULD 
> or MUST. This approach allows the IETF to publish RFCs that deal with a 
> wide range of crypto algorithms (national and otherwise) without 
> prejudice, without engaging in a protracted debate about whether all of 
> these algorithms are equally "worthy" etc. These WGs also define a small 
> number of mandatory (MUST or SHOULD), non-national algorithms, to promote 
> interoperability.

I get this argument.  The worry I have has something to do with either
the protocol environment or the use cases of the analogue protocols
you've picked.

In the case of IPsec and TLS, I believe (and I'm totally prepared to
be corrected) that there is a negotiation mechanism in place between
end points.  If I'm right about that, there's a serious disanalogy
here, because there's no possible way to make that negotiation work in
DNS (because of caches, and the way they might affect results).
That's perhaps unfortunate, but it's the protocol as we have it.

In the case of OPGP and S/MIME, the issue is different: these are
mostly protocols for people communicating with one another inside some
web of trust.  (I know, I know, S/MIME isn't like that, but it
immediately is in case we're using limited-deployment algorithms.)
The disanalogy here is different, but it has a similar force: if we
are going to continue to maintain the position that there's a global
DNS that's a universal service, then we have to discourage
non-implementation of algorithms that will freeze people out.

I've done my best to present above, as succinctly as possible, the
arguments against your argument.  I don't know that I've done their
partisans justice, but I'm trying to weigh each side.  So I'd
appreciate it if

    (1) those who agree with Steve could make their best arguments
    supporting his (do we need the secdir list for this?  Feel free to
    forward this, and you can direct replies to me for summary if
    desired)

and 
    
    (2) those who think I've made a weak case to follow up with
    stronger arguments.

A

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