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

Jeffrey Hutzelman <jhutz@cmu.edu> Thu, 11 February 2010 18:27 UTC

Return-Path: <jhutz@cmu.edu>
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 832233A786F for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 10:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.478
X-Spam-Level:
X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 OwinBwUriDGt for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 10:27:42 -0800 (PST)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 5101C3A7871 for <secdir@ietf.org>; Thu, 11 Feb 2010 10:27:42 -0800 (PST)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o1BISkxm023600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 13:28:47 -0500 (EST)
Date: Thu, 11 Feb 2010 13:28:46 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Andrew Sullivan <ajs@shinkuro.com>
Message-ID: <BC258F2990F871E42FBA3A36@lysithea.fac.cs.cmu.edu>
In-Reply-To: <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> <20100211181521.GG9592@shinkuro.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: secdir@ietf.org, Basil Dolmatov <dol@cryptocom.ru>, Ralph Droms <rdroms@cisco.com>, ogud@ogud.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:27:43 -0000

--On Thursday, February 11, 2010 01:15:23 PM -0500 Andrew Sullivan 
<ajs@shinkuro.com> 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's exactly as tight as I'm claiming; I simply omitted the details of 
the "unless..." part.



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

Yes.

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

When possible, yes.  But sometimes you can't do any better than mentioning 
things to think about, and sometimes you can't even do that.  SHOULD is 
really for those cases -- if it's possible to list the exceptions, then 
list them, and use MUST.


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

Certainly people do that.  But that doesn't mean we should further dilute 
the meaning of SHOULD by assuming that it will always be interpreted more 
loosely than intended, or by saying that a particular algorithm SHOULD be 
implemented when what we really mean is that we would like people to 
implement it.


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

Generally, if we believe the argument "I don't care about interoperating 
with foo" is a reasonable one, then saying "SHOULD foo" is just as wrong as 
saying "MUST foo".  SHOULD needs a good interop/security/stability reason 
just as much as MUST.


-- Jeff