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

From: Stephen Kent <[email-masked]>
Date: Tue, 9 Feb 2010 16:11:56 -0500

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.

>
>...
>>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.

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.

>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.

>>It imposes unacceptable costs on resolvers (analogous to RPs in the 
>>RPKI context)
>>
>RPs - are not resolver analogues, but this is for another discussion.

OK.

>>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.

We disagree on the nature of how costs may accrue.

>>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.

I'm glad we agree on this. Since SHOULD is only a slightly-diminished 
form of MUST, ...

>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.

>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).

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Feb 2010 15:35:52 -0600

> I'm glad we agree on this. Since SHOULD is only a slightly-diminished 

I'd add that if you "do agree that MUST set of algorithms should be very
narrow" then it follows...

...that you can't allow any nation to dictate that some sub-set of
algorithms must be added to the MUST set, because the moment you do all
comers will demand their alg suite be added and you no longer have a
"narrow" set of MUST-implement algorithms.

(Yes, I'm merely re-stating what has already been said.  But perhaps
this formulation will make the point clearer.)

Therefore the IETF policy seems quite right to me.  GOST can only become
a MUST- or SHOULD-implement algorithm only if we need one more algorithm
_and_ GOST is the best candidate.

That said...

> principle (if you'll pardon the term).

+1

...note too that I don't see why Russia couldn't make GOST support a
requirement for resolvers and DNS servers distributed in Russia.  They'd
want to sign their zones (at least top level ones) with RSA in addition
to GOST, but the burden of doing so would be minimal.

Any nation could take the approach of legislating MUST-implement sets
within their borders.

Note that failure to sign all the way to leaf zones with MUST-implement
algorithms is, effectively, a way of dividing the namespace, but at
least that would apply only to DNSSEC and not plain DNS.  Note too that
having national algorithms in the MUST-implement set wouldn't guarantee
that the root zone would be signed with them.  The only way to do that
would be through political agreements with, say, ICANN, or forking the
roots.

All of which leads me to this conclusion: adding national algorithms to
the DNSSEC MUST-implement list cannot achieve a political goal that
DNSSEC deployments use that algorithm.  So what would we get in exchange
for burdening implementors?  As far as I can see: nothing.

Nico
--

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Feb 2010 14:05:09 -0500

On Wed, Feb 10, 2010 at 09:06:31PM +0300, Basil Dolmatov wrote:
> 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.

My view has generally been that for each SHOULD, one needs to state
the cases under which one might not do the named thing.  So it's like
MUST EXCEPT.  If you want something truly optional, it's MAY.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 10 Feb 2010 21:06:31 +0300

Stephen Kent пишет:
>> I wondered why MUST and SHOULD are quoted together. I thought that it 
>> is two _different_ modal verbs with _different_ meaning and 
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).
> 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.
> 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.

> 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.
>
>
>> 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 
> 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. ;)

> 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@

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Feb 2010 14:26:30 -0500

>MUST EXCEPT.  If you want something truly optional, it's MAY.

Andrew,

Thanks for a better characterization of SHOULD vs. MUST than what I provided.

Steve

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Feb 2010 09:15:47 -0500

On Thu, Feb 11, 2010 at 12:33:24AM +0300, Basil Dolmatov wrote:
> Could you be so kind to point to a couple of examples of such usage of
> SHOULD in IETF documents?<br>
> Where SHOULD is used and exceptions&nbsp; are clearly listed.<br>
> <br>
> That will help to understand the situation with this verb better.<br>
> Thanks in advance,<br>

[Note that it's much easier for me if you send your mail multipart, so
I don't have to read plain HTML.]  

A good example of this style, I think, is in RFC 4308.  For instance, look at these bits:

   Implementations that use UI suites SHOULD also provide a management
   interface for specifying values for individual cryptographic options.
   That is, it is unlikely that UI suites are a complete solution for
   matching the security policies of many IPsec users, and therefore an
   interface that gives a more complete set of options should be used as
   well.

   IPsec implementations that use these UI suites SHOULD use the suite
   names listed here.  IPsec implementations SHOULD NOT use names
   different than those listed here for the suites that are described,
   and MUST NOT use the names listed here for suites that do not match
   these values.  These requirements are necessary for interoperability.

The first paragraph says you SHOULD provide a management interface,
because it's unlikely the UI suite is a complete solution for matching
the security policies.  By implication, the case in which you need not
provide the management interface is the case where the UI suite is
_guaranteed_ to provide the complete solution.  There could be such
cases, though (I can imagine an organization that had tight rules
about exactly what was allowed, and that could control the UI for
everyone).

The second paragraph says SHOULD and tells you what the requirements
are needed for.  By implication, if you don't care about
interoperability, then you could violate this.  (I like this example
because it's a bizarre exception, since the whole point of an RFC is
interoperability.)

Clearer?  (If not, trim the cc:s when following up: I doubt everyone
else needs to be seeing all this.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Basil Dolmatov <[email-masked]>
Date: Thu, 11 Feb 2010 00:33:24 +0300

Andrew Sullivan пишет:

MUST EXCEPT.

Could you be so kind to point to a couple of examples of such usage of
SHOULD in IETF documents?

Where SHOULD is used and exceptions  are clearly listed.

That will help to understand the situation with this verb better.

Thanks in advance,

dol@

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Feb 2010 11:29:55 -0500

At 9:06 PM +0300 2/10/10, Basil Dolmatov wrote:
>If SHOULD is used then "it is advised to have a code", but you can 
>omit it (after "careful weighting") and still be compliant.

I think Andrew's characterization is better than mine, and his 
follow-up message to you provied good examples.

>...
>>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 agree that there is a big difference between protocols where one 
can discover or negotiate protocol options and ones where this is not 
the case. But I believe that SIDR and DNESEC are pretty much the same 
in this respect. Both the RPKI and DNSSEC publish data that discloses 
what algs the publisher has chosen to employ. Relying parties either 
accommodate those choices or they do not make use of the signed data.

>>...
>>
>>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.

See Andrew's message, to which Im alluded above.
>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. ;)

OK. I'll interpret your comment as a comet warning :-).

>>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".

MUST and SHOULD are not the same, but they are no so different as you 
seem to suggest.

Steve

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Feb 2010 12:55:43 -0500

--On Thursday, February 11, 2010 11:29:55 AM -0500 Stephen Kent 
<[email-masked]> wrote:

> I think Andrew's characterization is better than mine, and his follow-up
> message to you provied good examples.
>
>> ...
> I agree that there is a big difference between protocols where one can
> discover or negotiate protocol options and ones where this is not the
> case. But I believe that SIDR and DNESEC are pretty much the same in this
> respect. Both the RPKI and DNSSEC publish data that discloses what algs
> the publisher has chosen to employ. Relying parties either accommodate
> those choices or they do not make use of the signed data.
>
>>> ...
>>>

It might be helpful for everyone to remember that while English has fairly 
loose definitions of "must" and "should", in this context MUST and SHOULD 
have precisely the meanings given them by RFC2119.  In particular, SHOULD 
is not mere advice or encouragement; it is a requirement almost as strong 
as MUST.  It doesn't mean "we think it's a good idea for you to do this"; 
it means "you absolutely have to do this unless...".

-- Jeff

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Feb 2010 13:15:23 -0500

On Thu, Feb 11, 2010 at 12:55:43PM -0500, Jeffrey Hutzelman wrote:

> SHOULD is not mere advice or encouragement; it is a requirement almost as 
> strong as MUST.  It doesn't mean "we think it's a good idea for you to do 
> this"; it means "you absolutely have to do this unless...".

To be fair to Basil, the actual text of 2119 is not as tight as you're
claiming:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

That seems to me to say that, as long as you know what you're doing
and have thought about it a lot, you can go ahead with your decision
not to do the RECOMMENDED thing and still be considered conforming.
The reason I prefer that authors and editors include the limiting
conditions is because of that "full implications" condition.  I think
that if you leave the full implications undefined, you're inviting the
reader to make their own determination.  Interoperability is not best
served thereby, so I think it better to state the
counter-considerations (even indirectly).

As Basil pointed out, there are plenty of SHOULDs in documents that
don't actually say when you're allowed to violate them.  In practice,
this means that people will violate them when it's really really
convenient, as opposed to the mere bar of convenient we get from MAY.
(Note that by this argument and with the current text, resolver
implementers could decide that they won't support GOST on the grounds
that their user base doesn't really need GOST, and they don't care
about interoperating with such an algorithm anyway.  Since there's no
limiting condition in the text, I'd be willing to make this argument
were I playing protocol lawyer.)

I also want to be clear that I'm not the DNSEXT shepherd for this
document, and I offically have no opinion one way or the other about
whether the language ought to be SHOULD or MAY.  I think I've said
that before, but I want to reiterate.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Feb 2010 13:28:46 -0500

--On Thursday, February 11, 2010 01:15:23 PM -0500 Andrew Sullivan 
<[email-masked]> wrote:

>> SHOULD is not mere advice or encouragement; it is a requirement almost
>> as  strong as MUST.  It doesn't mean "we think it's a good idea for you
>> to do  this"; it means "you absolutely have to do this unless...".
>

That's exactly as tight as I'm claiming; I simply omitted the details of 
the "unless..." part.

> not to do the RECOMMENDED thing and still be considered conforming.

Yes.

> counter-considerations (even indirectly).

When possible, yes.  But sometimes you can't do any better than mentioning 
things to think about, and sometimes you can't even do that.  SHOULD is 
really for those cases -- if it's possible to list the exceptions, then 
list them, and use MUST.

> convenient, as opposed to the mere bar of convenient we get from MAY.

Certainly people do that.  But that doesn't mean we should further dilute 
the meaning of SHOULD by assuming that it will always be interpreted more 
loosely than intended, or by saying that a particular algorithm SHOULD be 
implemented when what we really mean is that we would like people to 
implement it.

> were I playing protocol lawyer.)

Generally, if we believe the argument "I don't care about interoperating 
with foo" is a reasonable one, then saying "SHOULD foo" is just as wrong as 
saying "MUST foo".  SHOULD needs a good interop/security/stability reason 
just as much as MUST.

-- Jeff