Subject: [secdir] draft-ietf-karp-crypto-key-table-07

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Fri, 19 Apr 2013 14:05:22 +0000

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document is clear and easy to understand. I have a few comments/questions though:

* 1 Intro

What is conceptual about it? Isn't this supposed to be a specification of the format for a real database?

At this stage it is unclear to me where the database should reside, under control by whom etc.

* 2 Conceptual Database Structure

introductory paragraph: it is hard to grasp why or why not you want to have the same key appear twice without understanding what the format of the database will look like. So I think you should move that part of the first paragraph to below the column definition.

Peers: hmm, so now you have a multivalued column of arbitrary length? What is the separator? And do you expect normalisation into separate tables to happen?

Protocol: So here you want only a single security protocol, resulting in rows with the same key but different protocols. Resulting in a more complex lookup but no normalisation into separate tables necessary, I'd say best to choose one solution and stick to it. 

Sendlifetimestart: I don't see the need for the Z if you already specify that the format is UTC

* 3 Key Selection and Rollover

Do you only want to leave the choice of algorithm/ciphersuite to the client? How about including a preference in case of multiple entries for the same key? 

I understand the reason to select the latest SendLifeTimeStart, at the same time, if I want to minimise roll-over I might want to select the key with the latest AcceptLifeTimeEnd

I am wondering whether it makes a lot of sense to separate Send and Accept LifeTime, I can come up with some constructed examples  but I wonder how common that is, isn't it more typical to stop sending when you don;t want the peer to accept anymore, i.e. send=accept Lifetime?

* 7 Security Considerations

I would expect some wording on access to the database, whether the database is shared etc. The database seems an extremely interesting attack vector to me, basically by gaining write access to the database I control the security policy for the communication between the two peers.

Thanks,

Klaas

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Apr 2013 10:22:26 -0400

>>>>> "Klaas" == Klaas Wierenga (kwiereng) <[email-masked]> writes:

    Klaas> * 1 Intro

    Klaas> What is conceptual about it? Isn't this supposed to be a
    Klaas> specification of the format for a real database?

No.
It's exactly to avoid getting into a discussion of normalization and
most of the comments you discuss in your comments on section two that we
want this to be conceptual.
We don't want to go there because there is no interoperability advantage
to specifying things at that level of detail .

    Klaas> * 2 Conceptual Database Structure

    Klaas> introductory paragraph: it is hard to grasp why or why not
    Klaas> you want to have the same key appear twice without
    Klaas> understanding what the format of the database will look
    Klaas> like. So I think you should move that part of the first
    Klaas> paragraph to below the column definition.

    Klaas> Peers: hmm, so now you have a multivalued column of arbitrary
    Klaas> length? What is the separator? And do you expect
    Klaas> normalisation into separate tables to happen?

Since we're a conceptual database we don't need to answer any of that:-)
To describe the key selection algorithm we need to say it's a set.
To have interoperability within protocols we need each protocol to
define the format of a member of the set, but *not* how to represent a
set as a whole.

If we defined a netconf schema we might well need to define  how to add
and remove members from this set.

The natural way to do this will be vendor specific; the way I'd define a
IOS-style CLI would be very different than what I'd do for something
grabbing configuration from an SQL database.

    Klaas> Protocol: So here you want only a single security protocol,
    Klaas> resulting in rows with the same key but different
    Klaas> protocols. Resulting in a more complex lookup but no
    Klaas> normalisation into separate tables necessary, I'd say best to
    Klaas> choose one solution and stick to it.

In general, the protocol value is very likely to influence what keys are
valid.
We also want to strongly discourage the same key being used between
protocols.

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Fri, 19 Apr 2013 14:48:07 +0000

> Since we're a conceptual database we don't need to answer any of that:-)

hmm ok, I see your point

> We also want to strongly discourage the same key being used between

Yes, I understand that argument, but….. just like with peers you can argue that you don't have to answer any questions about whether you want extra records or multiple protocols per key in 1 record. It just suffices to say that you discourage the use of the same key for multiple protocols. Anyway, I don't feel strongly about this, it just felt inconsistent.

Klaas