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

Sam Hartman <> Fri, 11 October 2013 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC11D21E81B2; Fri, 11 Oct 2013 07:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.577
X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YeVakfZamSwK; Fri, 11 Oct 2013 07:48:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D688A21F9B4B; Fri, 11 Oct 2013 07:48:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23EAB204E1; Fri, 11 Oct 2013 10:47:09 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4LtmncORN0QO; Fri, 11 Oct 2013 10:47:08 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS; Fri, 11 Oct 2013 10:47:08 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 8731A82B26; Fri, 11 Oct 2013 10:48:34 -0400 (EDT)
From: Sam Hartman <>
To: Ben Campbell <>
References: <> <> <> <>
Date: Fri, 11 Oct 2013 10:48:34 -0400
In-Reply-To: <> (Ben Campbell's message of "Tue, 24 Sep 2013 17:46:40 -0500")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Sam Hartman <>,,
Subject: Re: [karp] Gen-ART LC Review of draft-ietf-karp-ops-model-07
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Oct 2013 14:48:45 -0000

>>>>> "Ben" == Ben Campbell <> 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 <> 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

    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.

how about replacing "and so on," with "and so on for  any additional
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.)

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..."

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.