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

Sandra Murphy <sandy@sparta.com> Mon, 25 January 2010 22:18 UTC

Return-Path: <Sandra.Murphy@cobham.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 4C5D33A68EF for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 14:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 o9RBPJZLVzTi for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 14:18:20 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2D9673A68E1 for <secdir@ietf.org>; Mon, 25 Jan 2010 14:18:20 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o0PMIESW008351; Mon, 25 Jan 2010 16:18:15 -0600
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o0PMIBY7007179; Mon, 25 Jan 2010 16:18:12 -0600
Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.114]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:18:11 -0500
Date: Mon, 25 Jan 2010 17:18:11 -0500 (Eastern Standard Time)
From: Sandra Murphy <sandy@sparta.com>
To: Basil Dolmatov <dol@cryptocom.ru>
In-Reply-To: <4B5B40FB.8060007@cryptocom.ru>
Message-ID: <Pine.WNT.4.64.1001251653100.2224@SANDYM-LT.columbia.ads.sparta.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="281994304-17170-1264457891=:2224"
X-OriginalArrivalTime: 25 Jan 2010 22:18:11.0306 (UTC) FILETIME=[47B104A0:01CA9E0C]
Cc: Andrew Sullivan <ajs@shinkuro.com>, secdir@ietf.org, ogud@ogud.com, Ralph Droms <rdroms@cisco.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: Mon, 25 Jan 2010 22:18:21 -0000


On Sat, 23 Jan 2010, 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.


I disagree with this characterization of Steve's presentation.  He 
presented a technique to allow a local determination of the authorization 
of routing information.  His technique was not a technique for 
distribution of routing information and was not independent from the 
outside world.  Note also that locally originated routing information and 
RPKI information would flow to the outside world without effect.

--Sandy
   (sidr chair)


>
> 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@
>
>
>
>
>> Best,
>>
>> A
>>
>> 
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>