Hi, thanks for the response. Comments inline. I've removed sections that do not
appear to need further comment.
On Sep 17, 2013, at 1:29 PM, Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
wrote:
genart> -- This abstract claims that this draft is a discussion of
genart> issues. From that per spective, I don't think the use of
genart> 2119 language is appropriate. There are some specific areas
genart> (mentioned below) where 2119 language is used in imprecis
genart> ways, and may do harm to the reader's understanding. There
genart> are other uses that may be more reasonable. But I think the
genart> draft would be better off dispensing with 2119 language
genart> altogether.
We disagree.
I think that the draft provides requirements that if followed will make
management of the security aspects of routers easier to depend on.
I believe 2119 language is useful in that.
I think that would be true if the intent of this draft was to create a BCP, or
something to that effect. That's not what the abstract and intro say. They
characterize the draft as "discussing issues" and "begins to develop a model".
If you think 2119 language is appropriate, then it might be helpful to update
the abstract and intro to make it more clear that the draft offers normative
guidance, and make it clear when and to whom it applies. For example, section 3
says "Implementations of this model MUST..." It's not clear to me what "this
model" means when the abstract and intro make it sound like this draft is early
work towards eventually developing such a model.
Bottom line is, I think the problem is not with 2119 language in general so
much as it is a matter of the draft being inconsistent on whether it is
discussing issues that may eventually lead to a model, or actually describing
such a model.
I think this is well within an area where there is no IETF-wide
consessus and the judgment of the individual WGs and to a lesser extent
editors should control.
Certainly. All I am doing is offering an opinion.
genart> -- Section 3, paragraph 4:
genart> This seems like a place where descriptive language would be
genart> better than 2119 lan guage. In particular, "and so on"
genart> leaves things too open ended and imprecise. Al so, the use
genart> of 2119 language in an example seems a bit off.
So, the requirement is stated in the first clause using 2119 language:
Operational Requirements: implementations of this model MUST support
configuration of keys at the most general scope for the underlying
protocol;
The sentence goes on to apply that requirement to some common cases:
protocols supporting per-peer keys MUST permit
configuration of per-peer keys, protocols supporting per-interface
keys MUST support configuration of per-interface keys, and so on.
You might prefer different style rules; you might prefer that the
restatements of the general requirement to specific situations not use
2119 language.
I think the right approach for that is to try and build community
consensus on those style rules and not to apply those rules until such a
consensus is achieved.
I do agree that care should be used when using 2119 in a restatement,
but in this instance believe it is OK.
I've removed the 2119 language from the example, although I think it was
harmless.
Ok.
My concern was that it is open ended. The words "and so on" tells me that
there may be more normative requirements that the reader is left to infer. That
could make it hard to know if an implementation fully complies.
[snip]
genart> -- section 3.2, paragraph 2:
genart> What distinguishes SHOULD from "desirable" in this context?
genart> That is, why use 211 9 language for one and not the other?
The sentences including desirable are giving motivation for the
sentences including SHOULD.
That is the SHOULDS are the take-aways, the desirables are
expansions/explanations of why the SHOULDS make sense.
On re-reading that paragraph, I see your point and retract the comment.
genart> -- section 3.2, last paragraph: "Implementations SHOULD
genart> permit a configuration i n which if no unexpired key is
genart> available, existing security associations continu e using
genart> the expired key with which they were established."
genart> This may need further guidance. For example, it seems risky
genart> to do this silently.
I think this was explicitly discussed in the WG and is where we got in
our discussions.
There's discussion of alerts for security events elsewhere.
However I think the current text represents a fairly informed WG
consensus.
You are correct that there is separate text on notification of security events
(section 6.2), and that even mentions certificate expiration. But it doesn't
explicitly mention continuing to use an expired key. I think that's important
enough that it should be explicitly considered.
If it was explicitly discussed in the working group, it would be helpful to
document the trade-offs that were discussed.
[snip]
genart> -- section 4, 2nd to last paragraph:
genart> Seems like other disadvantages are worth mentioning. For
genart> example, the potential impact of a compromised CA.
I spent a few minutes trying to come up with an argument whether CA
compromise was better or worse than other systems compromise profile,
particularly focusing on central management system compromise in the
preshared key case.
I think it's difficult to come up with an argument about whether that's
actually a disadvantage of CAs in this case and I think getting
consensus would be non-trivial.
I also think that managing CA compromise can either be handled on the
cost axis (secure offline CA) or the complexity axis (push out new CA
certs and end-entity certs on compromise).
So, I think the current text is accurate.
If there are specific disadvantages that can easily be verified, I'm
open to revisions.
The previous paragraph listed an advantage that the fact that a server only has
it's on key material limits the scope. The idea of a compromised CA having a
potentially very large scope of damage is pretty well known, and it's a very
real concern given the news of late. How that compares to the compromise of a
central management system depends on whether the CA is a "third party" (or as
in the web browser case, many third parties) vs the operator itself. (I guess
the central management system could also be a third party, but that may be less
typical.)
OTOH, the idea that a PKI is more costly is hard to verify without a
cost-benefit analysis about the CA costs compare to the operational savings.
genart> -- 4.1:
genart> I understand why one might choose not to include a
genart> real-world example here, but is there something that can be
genart> referenced?
Real wmorld example of what?
Sorry, that was for section 4.1.2: "This hypothetical example is overly
simplistic; real-world attacks exploiting key separation weaknesses tend to be
complicated..."
genart> Nits/editorial comments:
genart> Abstract: Might be worth mentioning KARP and how this draft
genart> fits with others.
I think this doesn't belong in the abstract.
I think we do cover this in the body of the document.
It's pretty common that when a draft is part of a larger body of work, that it
be mentioned in the abstract. People look at abstracts to determine if they
need to read the draft in the first place.
[snip]