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

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

Return-Path: <uri@mit.edu>
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 6964D3A69DC for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 05:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb5Lzb+PdGNt for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 05:37:57 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 36A2A3A69C2 for <secdir@ietf.org>; Mon, 25 Jan 2010 05:37:57 -0800 (PST)
X-AuditID: 1209190d-b7b0fae000000ead-c4-4b5d9eba50f5
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by dmz-mailsec-scanner-2.mit.edu (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 (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by grand-central-station.mit.edu (8.13.6/8.9.2) with ESMTP id o0PDcTal028812 for <secdir@ietf.org>; Mon, 25 Jan 2010 08:38:29 -0500 (EST)
Received: from webmail-9.mit.edu (WEBMAIL-9.MIT.EDU [18.9.23.19]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o0PDcKoC027692 for <secdir@ietf.org>; Mon, 25 Jan 2010 08:38:20 -0500 (EST)
Received: from webmail-9.mit.edu (webmail-9.mit.edu [127.0.0.1]) by webmail-9.mit.edu (8.13.8) with ESMTP id o0PDMaAE008586; Mon, 25 Jan 2010 08:22:36 -0500
Received: (from nobody@localhost) by webmail-9.mit.edu (8.13.8/8.13.8/Submit) id o0PDMaQH008585 for secdir@ietf.org; Mon, 25 Jan 2010 08:22:36 -0500
X-Authentication-Warning: webmail-9.mit.edu: nobody set sender to uri@mit.edu using -f
Received: from 206.53.147.102 ([206.53.147.102]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Mon, 25 Jan 2010 08:22:35 -0500
Message-ID: <20100125082235.uaq0dh6twos8so4w@webmail.mit.edu>
X-Priority: 3 (Normal)
Date: Mon, 25 Jan 2010 08:22:35 -0500
From: Uri Blumenthal <uri@MIT.EDU>
To: secdir@ietf.org
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]> <4B5D1F85.1070900@cryptocom.ru>
In-Reply-To: <4B5D1F85.1070900@cryptocom.ru>
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-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 13:37:58 -0000

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


Quoting Basil Dolmatov <dol@cryptocom.ru>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
>
>