Last Call Review of draft-ietf-karp-crypto-key-table-07
review-ietf-karp-crypto-key-table-07-secdir-lc-wierenga-2013-04-25-00

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