Hi Joe,
My own reactions below...
On 11/08/15 19:11, Joe Touch wrote:
(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.
I don't know what analogy you mean. The status change document
only says:
"The closest precedent we have for this status chage is the change of
RFC20 to Internet Standard. [4] That shows that if the text of an RFC
is acceptable, the age of the RFC isn't material in discussing proper
RFC status."
I think that's just useful information as that specific point was I
think raised when the RFC20 status change was considered.
That is a
factual document; this is an op-ed piece.
I don't think that's a relevant process point at all.
- 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
Again, that doesn't seem to me to be any kind of process
objection of substance. We can and do change the status of
RFCs without modification, sometimes to historic sometimes
not. If you object to such status changes then you need to
write an I-D I guess that changes the process. (In case it
helps see [1] for the list of recent status changes that
were last called as in-place status changes.)
[1] https://datatracker.ietf.org/doc/rfc-status-changes/
As a content issue:
- we cannot issue a "last call" on a BCP unless
the doc is open for edits
The last-call is not on the RFC but on the status-change document.
That can succeed or not. One of the possible outcomes to such a
last call is to decide to edit the relevant RFC, in which case
the status change would not happen. I see no process nor content
issue here that I understand.
- BCPs should make recommendations to protocol
designers, users, implementers, and operators
See my earlier answer to Roy. [2]
[2] https://www.ietf.org/mail-archive/web/ietf/current/msg94274.html
this document speaks more to governments,
I disagree. Again I'd point at my earlier answer to Roy.
which is
a policy role I feel ought to stay closer to the ISOC
and out of the IETF/IRTF
I think folks generally agree that such policy things are better
left to ISOC. I think it's equally clear that for example you and
I wouldn't agree on what we consider policy things in all cases.
While I appreciate the kitsch of desperately clinging to the originally
Kitsch and "desperately clinging" are purely pejorative I think.
issued RFC number,
I don't myself think that's such a big deal but if we have a way to
keep 1984 as the number, doing so is cute and worth doing I'd say.
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.
We disagree. See below for some responses.
Joe
----
- the fact that lazy programming is the cause of a large
amount of security issues (buffer overrun)
Off topic. This is not a document trying to cover all vulnerabilities
nor important ones, nor rank vulnerabilities.
- the concept that "crypto everywhere" is as vacuously useful
as "crypto nowhere"
I don't find that concept in the document at all, nor in any relevant
IETF document. You seem to be knocking down a non-existent strawman.
- it makes no direct key size recommendation (as a BCP should)
Off topic. This is not recommending use of specific algorithms (where
key size/strength becomes an issue) but the non-use of a class of
crypto that forces one to do key escrow of the kind described. This
is not a generic crypto primer nor HOWTO nor a BCP about how to use
crypto in IETF protocols. You seem to be criticising some document
which is not RFC1984 that you would prefer was the subject of an IETF
last call, but the detail of what is not here but in that non-existent
document is not useful in the context of this IETF last call I believe.
(Note I refer back to this point a number of times below when I say
"see above.")
- it makes no algorithmic diversity recommendation (as, IMO,
a crypto BCP should)
Off topic, see above. (Separately, I would welcome your comments on [3]
which is also currently in IETF LC btw.)
[2] https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/
- it makes no statement on the computational complexity of
crypto algs and their relationship to adoption and deployment
(as, IMO, a crypto BCP should)
Off topic, see above.
- it makes a claim about certification authorities being
both legitimate and necessary, when they are the antithesis
of some valid and useful crypto systems
Legitimate is fine, necessary is ok in that context and both are
actually about the abstract concept of a PKI which I think is
still considered basically correct. While we might use the work
"necessary" there were we to write this today, that I think is
ok.
- 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?)
That is not a quote from 1984. You seem to be criticising text that
is not there? Or are you postulating some other BCP about PKIs?
(i.e., "key signing parties are a hazard to public key crypto"
IMO)
Same problem as above - the quoted text above is not a quote from
1984.
- 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
All 4 of the above points are IMO off topic, so once again: see above.
The list goes on.
The problem with your list is that it is not dealing with this last
call of the status change of RFC1984 I think. It really looks to me
like you're saying that there is some other document that you would
prefer be written. That's a fine wish, but I don't think the details
of what you think ought be in that document are very useful in terms
of helping the IESG evaluate this last call.
Cheers,
S.
----