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

Basil Dolmatov <dol@cryptocom.ru> Wed, 10 February 2010 18:05 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 BD2663A6F03 for <secdir@core3.amsl.com>; Wed, 10 Feb 2010 10:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.129
X-Spam-Level:
X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875]
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 sHCiX9kaNrnY for <secdir@core3.amsl.com>; Wed, 10 Feb 2010 10:05:24 -0800 (PST)
Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 6073B3A777B for <secdir@ietf.org>; Wed, 10 Feb 2010 10:05:23 -0800 (PST)
Received: from [192.168.63.201] (ppp91-76-231-25.pppoe.mtu-net.ru [91.76.231.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 5F51A46602; Wed, 10 Feb 2010 21:06:32 +0300 (MSK)
Message-ID: <4B72F5A7.3050308@cryptocom.ru>
Date: Wed, 10 Feb 2010 21:06:31 +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]> <4B5D1F85.1070900@cryptocom.ru> <p06240801c7837dde3143@[192.168.0.187]>
In-Reply-To: <p06240801c7837dde3143@[192.168.0.187]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Wed, 10 Feb 2010 11:13:07 -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: Wed, 10 Feb 2010 18:05:25 -0000

Stephen Kent пишет:
> Basil,
>
> Sorry that I seem to have lost your message in my inbox for a while. 
> Replies inline below.
>
>>> ...
>> 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.
>
> SHOULD is MUST with an allowance for "carefully weighed" exceptions. 
> Both indicate that a compliant implementation ought to have code that 
> supports the referenced feature. In this case, that would be code to 
> support GOST algs.
Good shift in modal verbs <girn>.
I am fully agree that implementations "ought to have" but not "must 
have" a code.
This is the difference between MUST and SHOULD as I understand it.
If SHOULD is used then "it is advised to have a code", but you can omit 
it (after "careful weighting") and still be compliant.
If MUST is used - then you must have a code, otherwise you are not 
compliant. No options. Period.

>> 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.
>
> The local TA management capability that I have described for SIDR is 
> intended to deal with the general problem of an RP (or a sovereign 
> entity) wanting to create and manage a local view of the RPKI. It is 
> not primarily designed to accommodate national algorithms, although it 
> can be used for that was well.
That's right. I tried to find a way and found it in with capability 
which has been developed for somewhat different purpose.
>
>> 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.
>
> Oh, "castrate" seems like a pretty harsh term to use :-). Both the 
> RPKI and DNSSEC are flexible protocols.

> We're debating the issue of how broad a set of algorithms MUST/SHOULD 
> be supported by RPs, which is an architectural (and political) issue.
Having no means to inform other side about algorithms used is the thing 
that differs SIDR from DNSSec.

>>>
>> 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.
> 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'm glad we agree on this. Since SHOULD is only a slightly-diminished 
> form of MUST, ...
Either SHOULD is the synonym of MUST and then the question rises what it 
is present for if there is no real difference between it and MUST (it 
"should" <grin> be named as obsolete), or SHOULD has it's own meaning 
and should not be treated in discussions as MUST equivalent.
>
>> 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.
>
> Some might interpret this as a threat, even though I'm sure you didn't 
> mean it that way.
>
I want to make a reservation that I am not native English speaking 
person, so sometimes I use only literal meaning of the words when 
writing (and reading).
In order to clarify I will use an example from my profession (I am a 
physicist):

Imagine that one astronomer will estimate the orbit of some comet and 
say that "It is likely to hit the Earth".
Will it be the "threat" from the astronomer to the Earth? No, I think 
that it will be just a "warning note", because the astronomer have no 
influence on this process, he can only calculate the orbits of comets.
Definitely, some people could say that "this astronomer threats us with 
this comet", but it seems obvious that it is not the case. ;)

>> 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.
>
> Unified is a goal we both agree upon, but mandated support for 
> national algorithms is NOT a unifying principle, it is a Balkanizing 
> principle (if you'll pardon the term).
I am not familiar with this term and once more I object against putting 
the equal sign between MUST and SHOULD modal verbs.
I still think that there is a significant difference between them which 
is worth keeping both of these verbs in the list of instruments of IETF 
standards description.

So, noone is talking about "mandated support" (which means MUST), the 
bottom line is "to encourage support".

dol@

>
> Steve
>