Subject: [dnsext] Re: draft-ietf-dnsext-dnssec-registry-fixes vs. draft-ogud-iana-protocol-maintenance-words

From: Alfred Hönes <[email-masked]>
Date: Mon, 11 Jan 2010 12:29:38 +0100 (MEZ)

In the message archived at
<http://ops.IETF.ORG/lists/namedroppers/namedroppers.2010/msg00007.html>,
Jelte Jansen wrote:

> That prompted me to take a quick look at the normative-referenced but
> still very draft-y draft-ogud-iana-protocol-maintenance-words-02.
> DISCOURAGED is MUST-implement-this but discouraged-to-use, while
> ENCOURAGED is SHOULD-implement-this. That first one sounds wrong (note
> that i haven't followed discussion on that one at all, or seen it
> actually).
>
> Should we even publish this draft (reg-fixes) before maintenance-words
> is out? Not that I advocate more slowness in general, but it seems wrong
> to make a standards track document that adds a column with values that
> aren't defined yet...

Note that draft-ogud-iana-protocol-maintenance-words already is
in state PUBLICATION REQUESTED.  There have been a few discussions
early in December, and AFAICS, the responsible AD is waiting for a
revised draft version before issuing IETF LC, and Scott is working
on it.  (One particular procedural question raised was the intended
status, BCP vs. PS.)

So chances are good that draft-ogud-iana-protocol-maintenance-words
will be out for publication before any draft depending on it and
still in this WG can catch up towards publication.

The "MUST-implement" for DISCOURAGED has been discussed.  The
rationale so far was that an algorithm in this state will usually
previously have been ENCOURAGED or MANDATORY, and hence it is
expected that deployed implementations depend on it; to ensure
a smooth phasing out of such implementations without disruption,
it is wise to still require implementation of such algorithms.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 11 Jan 2010 12:54:36 +0100

On 01/11/2010 12:29 PM, Alfred � wrote:
> There have been a few discussions early in December,
> 

My google skills seem to be aware of it being monday today, and i
have a hard time finding that discussion, so let me apologize if
i am repeating arguments that have been made already.

> it is wise to still require implementation of such algorithms.

That's the thing, for the path MANDATORY->DISCOURAGED->OBSOLETE, this
makes complete sense. However, if you take
ENCOURAGED->DISCOURAGED->OBSOLETE it's a bit weird; suddenly a SHOULD
implement becomes a MUST implement, because we're trying to get rid of
the feature...

(and in the case of RSA/MD5, to stay a bit on topic, i guess 'NOT
RECOMMENDED' becomes 'OBSOLETE' because 'DISCOURAGED' would actually be
stronger than the current status. But OBSOLETE is also stronger in
another way. Either choice actually changes the current value, so the
document does make a 'new' statement about it)

Jelte

---

From: Alfred Hönes <[email-masked]>
Date: Mon, 11 Jan 2010 13:43:04 +0100 (MEZ)

Jelte Jansen wrote:
> On 01/11/2010 12:29 PM, Alfred Hönes wrote:

In the lack of a proper 'home' mailing list, at least my part of the
discussion of the maintenance-words draft has been off-list with the
authors (since the -00 draft), and the outcome is visible in the
diffs between the draft versions.
(See also my trailing remark below.)

> That's the thing, for the path MANDATORY->DISCOURAGED->OBSOLETE,
> this makes complete sense. However, if you take
> ENCOURAGED->DISCOURAGED->OBSOLETE it's a bit weird; suddenly a
> SHOULD implement becomes a MUST implement, because we're trying
> to get rid of the feature...
> 

Well, I had purposely reported "the rationale so far".
Personally, I would equally well favor demoting the implementation
requirement for DISCOURAGED from "MUST" to "SHOULD".

I thought the expected IETF LC discussion on the IETF main list
would be the proper place for such discussion, since the scope
of that draft far exceeds the scope of DNSEXT. ...

Kind regards,
  Alfred.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 11 Jan 2010 08:02:37 -0500

<no-hat>

At 07:43 11/01/2010, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>Jelte Jansen wrote:
> > On 01/11/2010 12:29 PM, Alfred HÎnes wrote:

It is fine to have this discussion here for now,
is:

         ENCOURAGED --> OBSOLETE is better than going through DISCOURAGED.
         Olafur

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 12 Jan 2010 09:23:24 -0500

I think draft-ogud-iana-protocol-maintenance-words, at least in its current
state, tries to encode way too many different dimensions into way too few
words.

I believe the existing clear and well understood implementation requirements
(MUST, SHOULD, MAY, SHOULD NOT, MUST NOT) should be preserved. If you want
to add an indication of predicted future implementation requirement state,
that should be done by an explicit additional indicator, such as a suffix
"+" or "-". Trying use just a few single words and also implicitly encoding
operational requirements as well as implementation really seems like it is
trying to force things into too few a number of cubbyholes.

Donald

PS: Defining RESERVED and AVAILABLE is fine.
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 12 Jan 2010 11:13:14 -0500

This draft came from the registry-fixes draft.  While going through the
docs, discussions, etc. I noticed that the word "mandatory" was never
defined and the other RFC 2119 keywords were too static in that there was no
way to convey intent and possible future action.

We looked at the +/- and noticed that it wasn't formally defined in a
document and the words were re-defined in every doc they were in (usually
the same text).  Most non-crypto/security folks were confused of the use, so
we thought it might be more readable to have set of new words for a more
formal meaning. The would obviously be a mapping from the use of +/- to the
newly defined terms.

Scott

On 1/12/10 9:23 AM, "Donald Eastlake" <[email-masked]> wrote:

> (MUST, SHOULD, MAY, SHOULD NOT, MUST NOT) should be preserved. If you want to
> add an indication of predicted future implementation requirement state, that
> should be done by an explicit additional indicator, such as a suffix "+" or
> "-". Trying use just a few single words and also implicitly encoding

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 12 Jan 2010 20:20:20 +0100 (MEZ)

Donald Eastlake wrote:

>> ...
>> I believe the existing clear and well understood implementation
>> requirements (MUST, SHOULD, MAY, SHOULD NOT, MUST NOT) should be
>> preserved. If you want to add an indication of predicted future
>> implementation requirement state, that should be done by an
>> explicit additional indicator, such as a suffix "+" or "-".
>> Trying use just a few single words and also implicitly encoding
>> operational requirements as well as implementation really seems
>> like it is trying to force things into too few a number of
>> cubbyholes.

... and in his response, Scott W. Rose wrote:

> We looked at the +/- and noticed that it wasn't formally defined in
> a document and the words were re-defined in every doc they were in
> (usually the same text).  Most non-crypto/security folks were confused
> of the use, so we thought it might be more readable to have set of new
> words for a more formal meaning.  The would obviously be a mapping
> from the use of +/- to the newly defined terms.

Please note (this has been pointed out already) that in 2008,
draft-hoffman-additional-key-words-00  tried to establish these
"+"/"-" keywords, motivated by similar requirements from IPSECME,
TLS, PKIX, and SMIME WGs.  However, this effort did not socialize
with the IETF at large and, reportedly, the IESG in particular.

The trouble with the RFC 2119 keywords, and requirements language
in the IETF in general, is that -- unlike some other SDOs -- the IETF
does not specify complete "solutions" but protocol building blocks,
and that therefore the RFC 2119 keywords are always "relative to
the document" in which they are used, i.e.:
  if an only if an implementation adheres to RFC zzzz,
    then the "MUST"s and "SHOULD"s therein are normative for it.

All IETFers see RFC 2119 keywords in this vein, and in particular
they are seen as (almost) temporally invariate: you need a new
RFC updating RFC zzzz to change the requirement levels therein.

What is needed for guidance to implementations regarding crypto
agility however are requirement keywords at a higher, 'meta' level,
not bound to the specifications of the algorithmic building blocks.
The requirements inside these specifications (and thereby 'relative'
to these specifications) remain unchanged.

It is expected that these requirements at the meta level may change
much more rapidly than the IETF is able and/or willing to revise
major protocol documents that could legitimately contain such
cookbook-like requirements for subordinate crypto algorithms.

One objective of the effort with such keywords is to encourage
implementation an (at least) small-scale use of new algorithms to
ensure properly tested and ready-to-use implementations are getting
available for newer (hopefully stronger) algorithms, without
immediately declaring existing implementations as nonconformant.
This way, in case progresses in cryptanalysis and/or computing power
make it advisable to quickly phase out use of an older algorithm,
the operational shift to a newer algorithm is much more easily
to perform.

Therefore, it is desirable to use keywords for this purpose that
can be distinguished easily from the RFC 2119 keywords, and it is
necessary to have requirements levels that can easily be recognized
as transitory in nature and/or expressing expected evolution.

Time already is tight for the first important use case:
NIST has announced phasing out SHA-1 support in digital signature
methods within its scope,  by the end of this year (2010), IIRC.

Colophon

Please note that recent anecdotal evidence shows that even much
less 'deep' details in security protocols can cause trouble if the
transition to new specifications fulfilling improved requirements
is not managed properly.  Giving the market a strong incentive for
the implementation of new algorithms and data formats without
declaring the deployed base non-conformant immediately is a strong
policy.  Failing to do so incurs the risk of unexpected trouble
with poorly implementend and/or poorly tested code.

The original CCITT X.208 ASN.1 specification only contained a single
'built-in' standard "UTCTime" ASN.1 type for calendar date plus time,
and that contained only two decimal digits for the year.  Although
the Y2K problem already arrived on the horizon, the entire X.500 suite
and then the IETF PKIX specs were initially built on this data type
and did not use the better ASN.1 GeneralizedTime data type (using
4-digit years) specified in a more recent edition of X.208.

Until recently, based on the intent to conserve long-term stability
and standards-conformance of existing deployments, GeneralizedTime
was not made mandatory-to-implement.  Even RFC 5280 requires for
PKIX certificates:

  "Both notBefore and notAfter may be encoded as UTCTime or
   GeneralizedTime.
   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate
   validity dates in 2050 or later MUST be encoded as GeneralizedTime."

... but it made significant progress in requiring, for the first time,

  "Conforming applications MUST be able to process validity dates that
   are encoded in either UTCTime or GeneralizedTime."

RFC-to-be 5751 (S/MIME 3.2) will restate this essentially unchanged,
but with slightly better guidance for receiving agents.

IMHO, that is too conservative, and dangerous.

The recent Y2k01 bug in over 30 Mio. European payment chipcards
issued during the last ~two years reportedly is related to improper
support of validy date formats in the chipcards relative to calendar
dates in 2010 (and later).
(For the issue and its economical effects, see e.g.
  <http://www.h-online.com/security/news/item/Problems-obtaining-cash-from-German-ATMs-Update-894801.html>
and
  <http://www.h-online.com/security/news/item/EC-card-disaster-French-manufacturer-Gemalto-takes-responsibility-897991.html> ).

Kind regards,
  Alfred.

--

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 12 Jan 2010 15:00:18 -0500

Everyone will be confused by the new system at first, whether you use new
words or new "accents" like suffix "+" and "-". In fact, the main difference
would be that if you use new words, people will be more inclined to guess at
their meaning and may guess wrong.

Forgetting about +/-, which I happen to like, my initial and main complaint
was trying to encode too many dimension into too few different words. I
don't particularly feel that that complaint has been answered...

Thanks,
Donald

On Tue, Jan 12, 2010 at 11:13 AM, Rose, Scott W. <[email-masked]>wrote:

> requirements

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 12 Jan 2010 15:23:21 -0500

At 09:23 12/01/2010, Donald Eastlake wrote:
>I think 
>draft-ogud-iana-protocol-maintenance-words, at 
>least in its current state, tries to encode way 
>too many different dimensions into way too few words.
>
>I believe the existing clear and well understood 
>implementation requirements (MUST, SHOULD, MAY, 
>SHOULD NOT, MUST NOT) should be preserved. If 
>you want to add an indication of predicted 
>future implementation requirement state, that 
>should be done by an explicit additional 
>indicator, such as a suffix "+" or "-". Trying 
>use just a few single words and also implicitly 
>encoding operational requirements as well as 
>implementation really seems like it is trying to 
>force things into too few a number of cubbyholes.

I hear you,
This draft is an attempt to get a dialog going on what the vocabulary,
should be.
The main complication is to keep this simple and still combine
operational and implementation requirements and expectations.
As for the +/- the current definitions are more implementation
oriented and less operational.

The words that Scott and I selected are just first draft, we would love to
get constructive suggestions, we (mainly) selected words that are different
from what is in use already.

><mailto:[email-masked]>[email-masked]
>
>
>On Mon, Jan 11, 2010 at 8:02 AM, Olafur 
>Gudmundsson <<mailto:[email-masked]>[email-masked]> wrote:
><no-hat>
>
>