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

Nicolas Williams <> Tue, 09 February 2010 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E46643A7623 for <>; Tue, 9 Feb 2010 14:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.046
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id APCVwjWu1ssq for <>; Tue, 9 Feb 2010 14:05:15 -0800 (PST)
Received: from (sca-ea-mail-2.Sun.COM []) by (Postfix) with ESMTP id D690B3A6E04 for <>; Tue, 9 Feb 2010 14:05:01 -0800 (PST)
Received: from ([]) by (8.13.7+Sun/8.12.9) with ESMTP id o19M5trn007882 for <>; Tue, 9 Feb 2010 22:06:07 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o19M5sEo036481 for <>; Tue, 9 Feb 2010 15:05:54 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o19LZseP027068; Tue, 9 Feb 2010 15:35:54 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o19LZrL7027067; Tue, 9 Feb 2010 15:35:53 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to using -f
Date: Tue, 9 Feb 2010 15:35:52 -0600
From: Nicolas Williams <>
To: Stephen Kent <>
Message-ID: <20100209213552.GP1061@Sun.COM>
References: <p06240810c76be77be756@[]> <> <p06240818c76c1a38cbf8@[]> <> <> <p0624080bc78249fa2c22@[]> <> <p06240801c7837dde3143@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240801c7837dde3143@[]>
User-Agent: Mutt/1.5.7i
Cc: Andrew Sullivan <>,, Basil Dolmatov <>,, Ralph Droms <>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Feb 2010 22:05:16 -0000

On Tue, Feb 09, 2010 at 04:11:56PM -0500, Stephen Kent wrote:
> >I do agree that MUST set of algorithms should be very narrow and 
> >limited generally speaking to those algorithms by which root zone is 
> >signed.
> I'm glad we agree on this. Since SHOULD is only a slightly-diminished 
> form of MUST, ...

I'd add that if you "do agree that MUST set of algorithms should be very
narrow" then it follows...

...that you can't allow any nation to dictate that some sub-set of
algorithms must be added to the MUST set, because the moment you do all
comers will demand their alg suite be added and you no longer have a
"narrow" set of MUST-implement algorithms.

(Yes, I'm merely re-stating what has already been said.  But perhaps
this formulation will make the point clearer.)

Therefore the IETF policy seems quite right to me.  GOST can only become
a MUST- or SHOULD-implement algorithm only if we need one more algorithm
_and_ GOST is the best candidate.

That said...

> >Maybe this is the way the DNS system will develop, but now I think 
> >that the some effort to keep the DNS system united is justified.
> Unified is a goal we both agree upon, but mandated support for 
> national algorithms is NOT a unifying principle, it is a Balkanizing 
> principle (if you'll pardon the term).


...note too that I don't see why Russia couldn't make GOST support a
requirement for resolvers and DNS servers distributed in Russia.  They'd
want to sign their zones (at least top level ones) with RSA in addition
to GOST, but the burden of doing so would be minimal.

Any nation could take the approach of legislating MUST-implement sets
within their borders.

Note that failure to sign all the way to leaf zones with MUST-implement
algorithms is, effectively, a way of dividing the namespace, but at
least that would apply only to DNSSEC and not plain DNS.  Note too that
having national algorithms in the MUST-implement set wouldn't guarantee
that the root zone would be signed with them.  The only way to do that
would be through political agreements with, say, ICANN, or forking the

All of which leads me to this conclusion: adding national algorithms to
the DNSSEC MUST-implement list cannot achieve a political goal that
DNSSEC deployments use that algorithm.  So what would we get in exchange
for burdening implementors?  As far as I can see: nothing.