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

Andrew Sullivan <ajs@shinkuro.com> Thu, 11 February 2010 18:14 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 A843228C15E for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 10:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level:
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 x0LKhuPMW-2r for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 10:14:11 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2F8E63A753F for <secdir@ietf.org>; Thu, 11 Feb 2010 10:14:11 -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 35C8A1ECB4E8; Thu, 11 Feb 2010 18:15:25 +0000 (UTC)
Date: Thu, 11 Feb 2010 13:15:23 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Message-ID: <20100211181521.GG9592@shinkuro.com>
References: <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <p0624080bc78249fa2c22@[10.242.22.104]> <4B5D1F85.1070900@cryptocom.ru> <p06240801c7837dde3143@[192.168.0.187]> <4B72F5A7.3050308@cryptocom.ru> <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]> <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: secdir@ietf.org, Basil Dolmatov <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: Thu, 11 Feb 2010 18:14:12 -0000

On Thu, Feb 11, 2010 at 12:55:43PM -0500, Jeffrey Hutzelman wrote:

> SHOULD is not mere advice or encouragement; it is a requirement almost as 
> strong as MUST.  It doesn't mean "we think it's a good idea for you to do 
> this"; it means "you absolutely have to do this unless...".

To be fair to Basil, the actual text of 2119 is not as tight as you're
claiming:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

That seems to me to say that, as long as you know what you're doing
and have thought about it a lot, you can go ahead with your decision
not to do the RECOMMENDED thing and still be considered conforming.
The reason I prefer that authors and editors include the limiting
conditions is because of that "full implications" condition.  I think
that if you leave the full implications undefined, you're inviting the
reader to make their own determination.  Interoperability is not best
served thereby, so I think it better to state the
counter-considerations (even indirectly).

As Basil pointed out, there are plenty of SHOULDs in documents that
don't actually say when you're allowed to violate them.  In practice,
this means that people will violate them when it's really really
convenient, as opposed to the mere bar of convenient we get from MAY.
(Note that by this argument and with the current text, resolver
implementers could decide that they won't support GOST on the grounds
that their user base doesn't really need GOST, and they don't care
about interoperating with such an algorithm anyway.  Since there's no
limiting condition in the text, I'd be willing to make this argument
were I playing protocol lawyer.)

I also want to be clear that I'm not the DNSEXT shepherd for this
document, and I offically have no opinion one way or the other about
whether the language ought to be SHOULD or MAY.  I think I've said
that before, but I want to reiterate.

A

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