Subject: Re: Revised Last Call: 'SSH Transport Layer Encryption Modes' to Proposed

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2005 17:24:52 -0400

>>>>> "iesg" == The IESG <[email-masked]> writes:

    iesg> This last call is being reissued because this document
    iesg> contains a normative reference to an informational RFC:

    iesg> RFC 2144 The CAST-128 Encryption Algorithm. C. Adams. May
    iesg> 1997.

    iesg> It is customary to include normative references to
    iesg> informational documents describing cryptographic algorithms.
    iesg> However the procedures of RFC 3967 require that this
    iesg> normative reference be called out in the IETF last call.

For the record I'd like to say that RFc 3967 seems poorly considered
and I don't think strikes a reasonable balance between efficiency and
quality.

In particular RFC 3967 does not allow classes of documents such as
cryptographic algorithms to be exempted from last call notice, only
single documents.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2005 19:14:54 -0400

--On Wednesday, August 24, 2005 17:24 -0400 Sam Hartman 
<[email-masked]> wrote:

>     iesg> This last call is being reissued because this
> document     iesg> contains a normative reference to an
> informational RFC:
>
>     iesg> RFC 2144 The CAST-128 Encryption Algorithm. C.
> Adams. May     iesg> 1997.
>
>     iesg> informational documents describing cryptographic
> algorithms.     iesg> However the procedures of RFC 3967
> require that this     iesg> normative reference be called out
> in the IETF last call.
>
>
> For the record I'd like to say that RFc 3967 seems poorly
> considered and I don't think strikes a reasonable balance
> between efficiency and quality.
>
> In particular RFC 3967 does not allow classes of documents
> such as cryptographic algorithms to be exempted from last call
> notice, only single documents.

For the record,

	* Does your comment/ position above represent an IESG
	consensus or your minority position?
	
	* Can we expect to see a draft of 3967bis that contains
	specific text with the rules you prefer?

Even if one believes that it is desirable, 3967 already weakens 
traditional norms for documents on the IETF standards track.  A 
suggestion that further weakening is needed definitely calls for 
some discussion, at least IMO.

     john

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Aug 2005 19:29:42 -0400

> some discussion, at least IMO.

There is considerable historic variation between areas on this supposed
"norm"; I don't think it's appropriate to characterize 3967 as uniformly
"weakening" (or "strengthening") any norms.

In particular, there is a long-established tradition of specifying
cryptographic algorithms as "Informational" documents, and referring to
them from standards-track documents.

					- Bill

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2005 23:00:48 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> --On Wednesday, August 24, 2005 17:24 -0400 Sam Hartman

    >> algorithms.  iesg> However the procedures of RFC 3967 require
    >> that this iesg> normative reference be called out in the IETF
    >> last call.
    >> 
    >> 
    >> In particular RFC 3967 does not allow classes of documents such
    >> as cryptographic algorithms to be exempted from last call

    John> For the record,

    John> 	* Does your comment/ position above represent an IESG
    John> consensus or your minority position?

I have no idea.  It's my individual opinion; I was hoping by sharing
Iit I would either find agreement or disagreement and that would
inform my thinking about next courses of action.

I know of no IESG consensus on this action, although clearly the IESG
considered 3967 reasonable at time of approval.

Your point is well taken.

--Sam

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Aug 2005 08:48:33 +0300 (EEST)

> them from standards-track documents.

I think there needs to be separation of two different kinds of 
documents,

  1) informational, because the normative specification is elsewhere 
(usually another standards organization) and we could reference the 
normative spec directly, and just provide informative reference to the 
Info spec).

  2) informational document just because, well, the authors thought it 
would be easiest to write an informational document.  This is the 
normative specification, and it may or may not have had sufficient 
IETF or security review.

At least to me, these two categories should be treated differently. 
It is not clear which case this one belongs.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 25 Aug 2005 14:44:42 +0100

> normative specification, and it may or may not have had sufficient 

Cryptographic algorithms have been documented via informational RFC's
since at least rfc1320.  

Both of your types (standalone and external reference) are present
within the RFC set.  For example, the primary specification of MD4 and
MD5 can be found in RFC1320 and RFC1321, while other RFC3174 contains a
specification of SHA-1 and a reference to its primary specification,
FIPS 180-1.

There is no value in requiring documents to have normative references to
FIPS 180-1 instead of to RFC3174.

> At least to me, these two categories should be treated differently. 

Can you explain why?

Cryptographic algorithms are, in general, hard to use correctly. 
Security review of cryptographic protocols involves an assessment of
whether the specific algorithms used actually meet the requirements of
that protocol. 

This already puts the burden on the referencing document to ensure the
algorithm is appropriate.  Security reviewers can be expected to cry
foul if the only algorithm referenced is an unknown.  ("Bass-o-matic? 
you must be kidding...").

And security protocols should for the most part be algorithm-agile;
cases where they are not need to be specially justified in the
referencing document.

Exactly *how* the algorithm is referenced from the specification is, by
comparison, a trivial matter.  Like the new "all documents must have
IANA considerations sections even if they don't need one" requirement,
this appears to be another exercise in attempting to substitute
mechanized process for judgment.

					- Bill

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 24 Aug 2005 15:58:47 -0700

> cryptographic algorithms to be exempted from last call notice, only

For the record, I'd like to say that I disagree.

I think that if we search for an "easiest possible way to implement" the 
RFC 3967 requirement, we will end up with a single web-maintained document 
of "documents that are OK to refer to". Doing explicit action to add each 
sensible crypto document to that list as it comes out doesn't strike me as 
onerous.

                  Harald

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Aug 2005 10:50:12 +0300 (EEST)

On Thu, 25 Aug 2005, Bill Sommerfeld wrote:
[normative specification is in the RFC series, vs. somewhere else and 
just copied or described in an info/exp RFC]
> whether the specific algorithms used actually meet the requirements of

If the normative specification is done in the RFC series, I would 
expect that the specification should undergo adequate review.

Informational/Experimental do not include wider IETF review (though 
whether the IETF can really review these specifications is a good 
question in any case), and to a degree, not necessarily even IESG 
review.

The reason for "downref" rules is to prevent depending on lower 
stability/quality specifications.  The metric is very coarse.  There 
are probably good Informational/Experimental documents out there.  On 
the other hand, referencing the works of other SDOs normatively is 
fine -- thus getting back to the point "is the normative specification 
in the RFC series or somewhere else?".  The "other SDO Specification" 
allows value judgment on the quality of the normative specification 
(e.g., a simple web page might or might no qualify).