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

Uri Blumenthal <uri@MIT.EDU> Mon, 25 January 2010 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6964D3A69DC for <>; Mon, 25 Jan 2010 05:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.068
X-Spam-Level: **
X-Spam-Status: No, score=2.068 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zb5Lzb+PdGNt for <>; Mon, 25 Jan 2010 05:37:57 -0800 (PST)
Received: from (DMZ-MAILSEC-SCANNER-2.MIT.EDU []) by (Postfix) with ESMTP id 36A2A3A69C2 for <>; Mon, 25 Jan 2010 05:37:57 -0800 (PST)
X-AuditID: 1209190d-b7b0fae000000ead-c4-4b5d9eba50f5
Received: from (GRAND-CENTRAL-STATION.MIT.EDU []) by (Symantec Brightmail Gateway) with SMTP id 8E.6B.03757.ABE9D5B4; Mon, 25 Jan 2010 08:38:02 -0500 (EST)
Received: from (OUTGOING-LEGACY.MIT.EDU []) by (8.13.6/8.9.2) with ESMTP id o0PDcTal028812 for <>; Mon, 25 Jan 2010 08:38:29 -0500 (EST)
Received: from (WEBMAIL-9.MIT.EDU []) ) by (8.13.6/8.12.4) with ESMTP id o0PDcKoC027692 for <>; Mon, 25 Jan 2010 08:38:20 -0500 (EST)
Received: from ( []) by (8.13.8) with ESMTP id o0PDMaAE008586; Mon, 25 Jan 2010 08:22:36 -0500
Received: (from nobody@localhost) by (8.13.8/8.13.8/Submit) id o0PDMaQH008585 for; Mon, 25 Jan 2010 08:22:36 -0500
X-Authentication-Warning: nobody set sender to using -f
Received: from ([]) (User authenticated as uri@ATHENA.MIT.EDU) by (Horde MIME library) with HTTP; Mon, 25 Jan 2010 08:22:35 -0500
Message-ID: <>
X-Priority: 3 (Normal)
Date: Mon, 25 Jan 2010 08:22:35 -0500
From: Uri Blumenthal <uri@MIT.EDU>
References: <p06240810c76be77be756@[]> <> <p06240818c76c1a38cbf8@[]> <> <> <p0624080bc78249fa2c22@[]> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
X-Scanned-By: MIMEDefang 2.42
X-Brightmail-Tracker: AAAAAhKHxpgSh8kU
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: Mon, 25 Jan 2010 13:37:58 -0000

My humble opinion: GOST "MUST NOT" be "SHOULD", but "SHOULD" be "MAY". For
reasons Steve explained.

Quoting Basil Dolmatov <>ru>:
>       Stephen Kent пишет:   Re: review of
> draft-ietf-dnsext-dnssec-gost-05 At 9:33 PM +0300 1/23/10, Basil
> Dolmatov wrote: Andrew Sullivan Ô˯ÂÚ:
> BTW, we have had this discussion in SIDR, where the RPKI has a
> similar global scope and where Vasily had made a similar request for
> recognition of GOST algorithms. So far, that WG has said no, for the
> reasons I cited in my comments and above. The current plan there is
> to go with the two suite model I described above.
> Ok.  Thanks for this; it's useful feedback.    Andrew, I, being the
> participant in the quoted process, want to share my description of
> what had happened and I think that it will differ to some extent.
> I noted that RPKI and SIDR implementations having exactly no
> possibility to support different protocols will definitely meet the
> problems, which DNSSec is overcoming simply by its design.
> Steve, in his presentation showed the technology which gives
> possibility to given AS (or group of ASes) to build entirely
> independent system of distribution of routing information from the
> outer world. That was _the_other_way_ to handle possible protocol
> problems, just to present mechanism, which allows to split whole
> system into several entirely independent protocol domains.
> Comparing to DNS the IDR ideology is entirely different: DNS is
> wholistic and united service, but main IDR principle is the
> independence of routing decisions for any given AS.
> I also noted then that from my point of view the DNSSec protocol
> approach seems much more productive for the development of the
> network as a whole and maintaining its integrity, SIDR approach from
> that perspective seems a restrictive one and leading to the dead end
> in the near future.
> I would be very cautious when considering the borrowing of the
> technologies and approaches from SIDR to any other protocols and
> services, these technologies though allowing to "overcome" possible
> protocol problems in fact will lead to the network split.
> dol@
> Basil,
> I agree that there are differences between the DNS and RPKI
> contexts, but we disagree on the principle common aspects associated
> with how to accommodate multiple algorithms in both environments.
>  Yes, we do disagree in principles (see below).
> The question for both DNSSEC and SIDR/RPKI is how many algorithms
> relying parties MUST/SHOULD be   I wondered why MUST and SHOULD are
> quoted together. I thought that it is two _different_ modal verbs
> with _different_ meaning and _different_ implementation demands.
> required to implement, and how do we. The approach adopted (so far)
> in the SIDR context is to minimize such requirements, to not burden
> RPs, and to avoid creating the sort of potential security problems
> cited by Paul Hoffman. Thus the plan is to mandate support for two
> sets of algorithms (we have only one set so far), a current MUST
> implement and a next MUST implement.
> I believe that the situation for DNESEC is equivalent, i.e.,
> imposing a requirement (via MUST or SHOULD) to support more than a
> current and next set of algorithms is not justifiable.   The
> situation in DNSSec is entirely different from SIDR:
> Comparing to DNS the IDR ideology is entirely different: DNS is
> wholistic and united service, but main IDR principle is the
> independence of routing decisions for any given AS. The way that was
> chosen by SIDR developers is demanding to invent some methods and
> technologies to prevent network from being split.
> Thank you, Steve, you proposed one of the possible technologies which
> makes that possible (at least makes a forthcoming split more or less
> implicit).
> That does not mean that this technology is the _good_ one. It means
> that for the given set of circumstances this solution is
> _the_only_possible_ one.
> So, I quit the discussion in SIDR, not because of I was satisfied
> with the technology and solutions, but because of I have understood
> how I could maintain network interoperability even with this rigid
> technology and have had more urgent tasks to perform.
> I kindly ask to all participating parties do not try to castrate
> flexible protocol design of DNSSec to the SIDR/RPKI rigid approach.
> It imposes unacceptable costs on resolvers (analogous to RPs in the
> RPKI context)   RPs - are not resolver analogues, but this is for
> another discussion.
> and may have adverse secruity implications. Such externalization of
> costs is a fundamentally bad approach, one that the IETF tries to
> avoid in analogous contexts in all areas.
>  Here is another difference od DNSSec from SIDR - most of the
> software is open-source in DNSSec, so costs have been already
> distributed evenly.
> As for proprietary realisations it seems to me the maintaining of the
> cost/profit balance is the task of the management of the given
> enterprise, and I am sure that they will do their work well.
> It is fine for DNSEXT to allocate algorithm IDs to national
> algorithms like GOST, but it is not appropriate to mandate their
> support, for the reasons cited in my review.  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.
> As for the other algorithms, it seems to me that the main goal of DNS
> system is the providing integral name service resolution. If one have
> to perform some additional steps (install different resolver
> software, include something and something) just to get access to the
> network names on some part of the world, then the obvious next step
> will be to point this different resolver to another root of the tree.
> 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.
> dol@
> Steve