(forwarded from SAAG):
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.
----