Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
Stephen Kent <kent@bbn.com> Sun, 24 January 2010 19:14 UTC
Return-Path: <kent@bbn.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 611E33A68BD for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 11:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, HTML_MESSAGE=0.001]
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 jXD2J40IGGPC for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 11:14:11 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0E99F3A6824 for <secdir@ietf.org>; Sun, 24 Jan 2010 11:14:11 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.22.104]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NZ7uV-0006M8-Ae; Sun, 24 Jan 2010 14:14:11 -0500
Mime-Version: 1.0
Message-Id: <p0624080bc78249fa2c22@[10.242.22.104]>
In-Reply-To: <4B5B40FB.8060007@cryptocom.ru>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru>
Date: Sun, 24 Jan 2010 14:14:07 -0500
To: Basil Dolmatov <dol@cryptocom.ru>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-947762045==_ma============"
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: Sun, 24 Jan 2010 19:14:12 -0000
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. The question for both DNSSEC and SIDR/RPKI is how many algorithms relying parties MUST/SHOULD be 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. It imposes unacceptable costs on resolvers (analogous to RPs in the RPKI context) 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. 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. Steve
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Andrew Sullivan
- [secdir] review of draft-ietf-dnsext-dnssec-gost-… Stephen Kent
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Stephen Kent
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Andrew Sullivan
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Paul Hoffman
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Uri Blumenthal
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Andrew Sullivan
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Paul Hoffman
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… David McGrew
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Nicolas Williams
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Eric Rescorla
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Stephen Kent
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Basil Dolmatov
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Basil Dolmatov
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Uri Blumenthal
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Sandra Murphy
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Sandra Murphy
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Stephen Kent
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Nicolas Williams
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Andrew Sullivan
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Basil Dolmatov
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Stephen Kent
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Andrew Sullivan
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Basil Dolmatov
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Stephen Kent
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Jeffrey Hutzelman
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Andrew Sullivan
- Re: [secdir] review of draft-ietf-dnsext-dnssec-g… Jeffrey Hutzelman