Last Call Review of draft-ietf-karp-crypto-key-table-07

Request Review of draft-ietf-karp-crypto-key-table
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-04-29
Requested 2013-04-18
Authors Tim Polk, Russ Housley, Sam Hartman, Dacheng Zhang
Draft last updated 2013-04-25
Completed reviews Genart Last Call review of -07 by David Black (diff)
Genart Telechat review of -08 by David Black (diff)
Secdir Telechat review of -08 by Klaas Wierenga (diff)
Secdir Last Call review of -07 by Klaas Wierenga (diff)
Assignment Reviewer Klaas Wierenga
State Completed
Review review-ietf-karp-crypto-key-table-07-secdir-lc-wierenga-2013-04-25
Reviewed rev. 07 (document currently at 10)
Review result Has Issues
Review completed: 2013-04-25



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.