Subject: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Aug 2015 19:21:34 +0100

As promised... As it says below, please send comments if any
to [email-masked] (or exceptionally to [email-masked]).

Thanks,
S

-------- Forwarded Message --------
Subject: Last Call: Recognising RFC1984 as a BCP
Date: Mon, 10 Aug 2015 10:13:06 -0700
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual participant to make
the following status changes:

- RFC1984 from Informational to Best Current Practice
    (IAB and IESG Statement on Cryptographic Technology and the Internet)

The supporting document for this request can be found here:

https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-09-07. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The affected document can be obtained via
https://datatracker.ietf.org/doc/rfc1984/

IESG discussion of this request can be tracked via
https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ballot/

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2015 16:34:38 -0400

I disagree with this change of status. Documents that refer to this RFC informationally would all need to be considered for potential impact. 

This does not seem to be an appropriate change. If a BCP were appropriate, a bis revision should be the mechanism for upgrading the impact of the content. 

Joe

> On Aug 10, 2015, at 2:21 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 10 Aug 2015 21:14:42 -0400

On Mon 2015-08-10 16:34:38 -0400, Joe Touch wrote:
> I disagree with this change of status.

Is your disagreement on process grounds or because you disagree with the
analysis or sentiments expressed in RFC 1984?

> Documents that refer to this RFC informationally would all need to be
> considered for potential impact.

I just did a review of all RFCs that refer to RFC 1984 explicitly [0]

-------------

The RFCs are:

 * RFC 2804 ("IETF Policy on Wiretapping")

  [ reference is aggregated in "References" section, no distinction between
    normative/informative ]
    
   https://tools.ietf.org/html/rfc2804#page-2

>>    - The IETF restates its strongly held belief, stated at greater
>>      length in [RFC 1984], that both commercial development of the
>>      Internet and adequate privacy for its users against illegal
>>      intrusion requires the wide availability of strong cryptographic
>>      technology.

 * RFC 4322 ("Opportunistic Encryption using the Internet Key Exchange
   (IKE)")

   [ reference is in the "Informative References" section ]

  https://tools.ietf.org/html/rfc4322#section-1.1

>>    The Internet Architecture Board (IAB) and Internet Engineering
>>    Steering Group (IESG) have taken a strong stand that the Internet
>>    should use powerful encryption to provide security and privacy
>>    [RFC1984].  The Linux FreeS/WAN project attempts to provide a
>>    practical means to implement this policy.

 * RFC 7258 ("Pervasive Monitoring Is an Attack")

   [ reference is in "Informative References" section; there is no
     normative section ]

   https://tools.ietf.org/html/rfc7258#section-3

>>    In the past, architectural statements of this sort, e.g., [RFC1984]
>>    and [RFC2804], have been published as joint products of the Internet
>>    Engineering Steering Group (IESG) and the Internet Architecture Board
>>    (IAB).  However, since those documents were published, the IETF and
>>    IAB have separated their publication "streams" as described in
>>    [RFC4844] and [RFC5741].  This document was initiated after
>>    discussions in both the IESG and IAB, but is published as an IETF-
>>    stream consensus document, in order to ensure that it properly
>>    reflects the consensus of the IETF community as a whole.

-------------

None of these references (and none of these documents) seems to disagree
in any way with RFC 1984, or to be harmed or modified by its
confirmation after 19 years as a BCP.

Given that 2670 of the 7460 published RFCs have some mention of
cryptgraphy [1], and that at every month since the start of 2000 (i
haven't looked earlier) we've published RFCs mentioning cryptography, it
seems clear that encrypted communications is still something that we
believe in as a community, and are continuing to rely on.

I see no reason to revise our recommendation that we "would like to
encourage policies that allow ready access to uniform strong
cryptographic technology for all Internet users in all countries."

           --dkg

[0]
$ egrep -il 'rfc.?1984' rfc*.html 
rfc1984.html
rfc2804.html
rfc4322.html
rfc7258.html
$ 

[1] 
$ egrep -il '(en|de)crypt|crypt(o|ed|-hash|-pw|analy(sis|ze))' rfc*.html | wc -l
2670
$ ls rfc*.html | wc -l
7460
$

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2015 10:08:02 -0400

> Is your disagreement on process grounds or because you disagree with
    > the analysis or sentiments expressed in RFC 1984?

    >  * RFC 2804 ("IETF Policy on Wiretapping")

It might make sense to turn this into a BCP.

I agree with your analysis (in particular as the author of 4322, I agree)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 10:29:55 -0700

> analysis or sentiments expressed in RFC 1984?

Both.

As a process issue:

	- The analogy to ASCII  (RFC20) is not helpful. That is a
	factual document; this is an op-ed piece.

	- It makes sense to move existing RFCs to "Historic",
	but in all other cases (ASCII included) it is much
	more common and in keeping with the IETF process to
	issue a new RFC

As a content issue:

	- we cannot issue a "last call" on a BCP unless
	the doc is open for edits

	- BCPs should make recommendations to protocol
	designers, users, implementers, and operators

	this document speaks more to governments, which is
	a policy role I feel ought to stay closer to the ISOC
	and out of the IETF/IRTF

While I appreciate the kitsch of desperately clinging to the originally
issued RFC number, the document further lacks the clear and technical
advice to EVERYONE I expect for the topic covered. Some missing issues
are noted below.

IMO, a BCP on this topic should stick to the facts, avoid wandering into
policy and governmental issues, and make clear recommendations to the
IETF community. The current RFC fails in all these regards.

Joe

----

	- the fact that lazy programming is the cause of a large
	amount of security issues (buffer overrun)

	- the concept that "crypto everywhere" is as vacuously useful
	as "crypto nowhere"

	- it makes no direct key size recommendation (as a BCP should)

	- it makes no algorithmic diversity recommendation (as, IMO,
	a crypto BCP should)

	- it makes no statement on the computational complexity of
	crypto algs and their relationship to adoption and deployment
	(as, IMO, a crypto BCP should)

	- it makes a claim about certification authorities being
	both legitimate and necessary, when they are the antithesis
	of some valid and useful crypto systems

	- it fails to address the slipshod way in which public keys
	are often signed by others, e.g., using a "government issued ID"
	as proof (who of us would know an invalid ID if we saw one?)

	(i.e., "key signing parties are a hazard to public key crypto"
	IMO)

	- it makes no statement about the relationship of the keys to
	the data, i.e., it does not warn against bare reuse of keys
	(vs., e.g., using the keys with session info to derive a
	session key)

	- it does not address how salts or seeds are generated safely,
	and why using header fields you "don't know" isn't the same
	as using random info.

	- it fails to address ways in which actions, rather than
	content, expose information (e.g., the packet patterns)

	- it fails to address the potential benefit of out-of-band
	verification or salts

The list goes on.

----