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

[Joe Touch <[e-mail]>]

On 8/10/2015 6:14 PM, Daniel Kahn Gillmor wrote:
> 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?

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.

----