Re: [karp] Gen-ART LC Review of draft-ietf-karp-ops-model-07

[Ben Campbell <[e-mail]>]

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 <[e-mail]> 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]