>>>>> "Ben" == Ben Campbell <ben@xxxxxxxxxxx> writes:
Ben> Hi, thanks for the response. Comments inline. I've removed
Ben> sections that do not appear to need further comment.
Ben> On Sep 17, 2013, at 1:29 PM, Sam Hartman <hartmans-ietf@xxxxxxx> 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.
Ben> If you think 2119 language is appropriate, then it might be
Ben> helpful to update the abstract and intro to make it more clear
Ben> that the draft offers normative guidance, and make it clear
Ben> when and to whom it applies. For example, section 3 says
Ben> "Implementations of this model MUST..." It's not clear to me
Ben> what "this model" means when the abstract and intro make it
Ben> sound like this draft is early work towards eventually
Ben> developing such a model.
Having re-read the abstract and your comments I have a better
understanding of what you mean.
I've updated the abstract.
I think this should help a lot.
Sorry that I didn't get the version published last time; will upload
today.
>>
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.
Ben> Ok.
Ben> My concern was that it is open ended. The words "and so on"
Ben> tells me that there may be more normative requirements that the
Ben> reader is left to infer. That could make it hard to know if an
Ben> implementation fully complies.
Ah,
how about replacing "and so on," with "and so on for any additional
scopes?"
My hope is to make it clear that the additional requiresments are
related to any configuration scopes the protocol has.
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.
>>
Ben> The previous paragraph listed an advantage that the fact that a
Ben> server only has it's on key material limits the scope. The idea
Ben> of a compromised CA having a potentially very large scope of
Ben> damage is pretty well known, and it's a very real concern given
Ben> the news of late. How that compares to the compromise of a
Ben> central management system depends on whether the CA is a "third
Ben> party" (or as in the web browser case, many third parties) vs
Ben> the operator itself. (I guess the central management system
Ben> could also be a third party, but that may be less typical.)
Ah,
I don't think a third-party CA would make sense for KARP.
Which is why I find evaluating the tradeoff to be hard: I expect the CA
and central management systems would control the same machines.
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?
Ben> Sorry, that was for section 4.1.2: "This hypothetical example
Ben> is overly simplistic; real-world attacks exploiting key
Ben> separation weaknesses tend to be complicated..."
Agreed.
For others following the conversation, I'd appreciate a reference.
I'm finding good e-mail discussions, class-notes, etc, but nothing that
I can cite in an RFC.
I'd love to have a reference here.