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

Basil Dolmatov <dol@cryptocom.ru> Mon, 25 January 2010 04:35 UTC

Return-Path: <dol@cryptocom.ru>
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 60F8D3A6856 for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 20:35:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.807
X-Spam-Level: **
X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_SORBS_WEB=0.619]
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 hkDJo6f5GRAb for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 20:35:17 -0800 (PST)
Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 1D62E3A6358 for <secdir@ietf.org>; Sun, 24 Jan 2010 20:35:15 -0800 (PST)
Received: from [192.168.63.201] (unknown [91.78.157.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id B615E46466; Mon, 25 Jan 2010 07:35:18 +0300 (MSK)
Message-ID: <4B5D1F85.1070900@cryptocom.ru>
Date: Mon, 25 Jan 2010 07:35:17 +0300
From: Basil Dolmatov <dol@cryptocom.ru>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <p0624080bc78249fa2c22@[10.242.22.104]>
In-Reply-To: <p0624080bc78249fa2c22@[10.242.22.104]>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sun, 24 Jan 2010 22:57:34 -0800
Cc: Andrew Sullivan <ajs@shinkuro.com>, Ralph Droms <rdroms@cisco.com>, 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: Mon, 25 Jan 2010 04:35:18 -0000

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