(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. ----