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

["Klaas Wierenga (kwiereng)" <[e-mail]>]

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