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

[Uri Blumenthal <[e-mail]>]

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


Quoting Basil Dolmatov <[e-mail]>:
>       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
>
>