Re: IPS: Area Director View of SRP IPR

[David Jablon <dpj@theworld.com>]

Allison,

I think the following guidance from the ADs is inconsistent with RFC 2119.

At 06:52 PM 4/10/02 -0400, Allison Mankin wrote:
>In the absence of other information, the appropriate requirement level
>the ADs see for SRP is a "MAY", because "SHOULD" has implications in
>RFC 2119 that a strong technical reason should be at the root of
>electing not to implement. ...

First, RFC 2119 uses the term "valid reasons" rather than "strong
technical reason".  Regardless of what the author had in mind when
RFC 2119 was written, I think the important consideration is how it
is interpreted, in its entirety, in context, by all readers.

Natural questions to ask are what does RFC 2119 say about the difference
between MUST and SHOULD, and what does it say about the difference
between SHOULD and MAY, for a feature that has security implications?

Some excerpts are illustrative.  Regarding SHOULD vs. MAY:

>7. Security Considerations
>
>   These terms are frequently used to specify behavior with security
>   implications.  The effects on security of not implementing a MUST or
>   SHOULD, or doing something the specification says MUST NOT or SHOULD
>   NOT be done may be very subtle. Document authors should take the time
>   to elaborate the security implications of not following
>   recommendations or requirements as most implementors will not have
>   had the benefit of the experience and discussion that produced the
>   specification.

"Subtle" seems to exactly characterize the issues with SRP-* vs. *-CHAP,
presuming that a significant number of people believe that SRP-*
provides incremental security over *-CHAP.

Using "MAY" or less implies that there are no subtle security
considerations, which is clearly inappropriate in this case.

Regarding MUST vs. SHOULD:

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

The words "in particular circumstances", "full implications", and
"carefully weighed" seem especially appropriate in this case.

And if some blend of IPR and technical considerations are not deemed
to provide sufficiently "valid reasons" for the WG or IESG to downgrade
a MUST requirement to a SHOULD, thus permitting an implementor to
ignore the item, then a reasonable interpretation of RFC 2119 section 3
is that SHOULD and MAY are too weak, and the requirement should
preferrably remain a MUST.

Regarding MAY:

>5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>   truly optional.  One vendor may choose to include the item because a
>   particular marketplace requires it or because the vendor feels that
>   it enhances the product while another vendor may omit the same item.
>   An implementation which does not include a particular option MUST be
>   prepared to interoperate with another implementation which does
>   include the option, though perhaps with reduced functionality. ...

The question naturally arises whether "reduced functionality" can mean
"reduced security".  It seems that the answer is "not really", in
light of section 7.  Reduced security is something that merits
special consideration, which implies that either SHOULD
or MUST is the more appropriate word to use.

The words "truly optional" do not seem appropriate to any case
of an optional feature with potentially significant security
considerations that either the WG or the IETF in general care about.

As a practical matter, it also seems extremely difficult to separate
"technical reasons" from "other reasons" to implement/not-implement
or use/not-use a potentially IP-encumbered feature.
I think the WG debate has clearly shown that people intermingle
these concerns. The fact that we're talking about security features
makes it especially delicate and dangerous to use an arbitrary razor.

I believe that the valid debate in this WG is over the significance of the
security considerations, which should drive any MAY/SHOULD/MUST
wording decisions.

It may be appealing to the ADs to look for an administrative short-cut
or technicality to preempt this process, but it seems wrong.

-- David