Hi, Stephen,
As to the process issue, I see absolutely no rationale for not opening
this to a -bis style editing cycle except the hope of clinging to a
already issued RFC number.
As I've pointed out to others, there are cases where standards-track
docs have been promoted or demoted as-is because changing the doc would
mean changing the protocol. That's not an issue here.
As to the content:
On 8/11/2015 2:17 PM, Stephen Farrell wrote:
...
----
- 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.
It's a statement on "cryptographic technology and the Internet". AFAICT,
the biggest holes we have in that technology are in the sloppy
implementation.
- 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.
I'm saying that the document, as a BCP, ought to discuss how crypto is
used, and make the case that crypto should be used where needed. It is
not a panacea. The subtext of the current document hints otherwise.
- 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.")
Point taken, but my counterpoint is that a document that speaks to
governments and voters is "off topic" for the IETF.
But let's concede that we've both made that point and omit the remainder
that fall into that class...
...
- 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.
certification authorities are legitimate and necessary *for PKI*. There
are other systems, though (I would not consider PGP based on "PKI").
- 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'm claiming the document is flawed in not addressing this issue. If you
think it's OK to claim that certificate authorities are necessary, then
why is it OK for PGP to use haphazard keysigning parties?
(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.
Same thing - flawed by omission.
I consider this issue to be distinct from the more technical, specific
ones you claim are "off topic".
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.
A document that clearly indicates the technical reasons why certain
policies are ineffectual or inappropriate is fine. This document might
be a step in that direction, but it has problems that ought to be fixed.
A document that pontificates on those reasons has no purpose in the
IETF. I recognize that there are many others on this list who prefer to
waste their time endorsing such proclamations, but I will not.
Joe