Database of Long-Lived Symmetric Cryptographic Keys
draft-ietf-karp-crypto-key-table-10

Thank you for working on my Discuss and Comments.

My Discuss used to read...

> I am entering a short Discuss since my attempts to discuss this point
> by email have not produced a result.
>
> - Is this document intended to establish a registry for secure routing
>   protocols or for all security protocols? 
> - If general-purpose, how is this a legitimate product of the KARP 
>   working group? 
> - If specific to routing protocols how is this language in the
>   document consistent with that claim? 
> - Why is the registry populated only with 802.1X?
>
> Essentially, and bluntly, please convince me that you are not using
> the KARP working group as a way of introducing a registry (that may or
> may not have value) that is not used by KARP but has some other
> unstated purpose.

I was pretty sure we had this agreed, and I see that 802.1X has gone 
from the text, which is good because I don't believe it is used in 
routing security at this time. Just to note that 802.1X still shows as
a reference, so you need to clean that up.

However, I see that you have introduced some new references to pre-
populate the registries.
                                  
RFC 2104 for HMAC-SHA-1
RFC 2104 for HMAC-SHA-1-96
RFC 4493 for AES-128-CMAC
RFC 5926 for AES-128-CMAC-96

Some observations: 
- These initial population values are barely mentioned in the document.
  They do appear as examples in the description of the conceptual table,
  but there is no reference to routing security either through state of
  the art or work in progress.
- A quick search for (random example) RFC 4493 shows that it is cited
  by precisely one non-expired routing document.
- Perhaps the main point of AES-128-CMAC will come through RFC 5926 and
  the recommended use of TCP/AO to secure TCP-based routing protocols.

My conclusion is that you *are* pre-populating this table with 
reasonable values, but that you are not doing the work to justify why
you are adding these values.

Having satisfied myself that the values are relevant, I don't require
that you do additional work. But I think it would not be hard or a bad
idea to add a short section titled "Initial Table Population" that lists
the initial values and explains why they are there.

Minor point: there's an obvious (to most) formatting problem in Section 2, "AdminKeyName", introduced in -08.

This draft contains the use of several 2119 keywords, yet does not contain the 2119 boilerplate or a reference to 2119.

I think the Section 3 text about IPsec and its PAD is still not clear enough that *that* table has nothing to do with the table definition in *this* document.

I would like to talk with the authors/WG about why FCFS is the appropriate policy for the KDFs and algorithm identifiers. Can someone tell me the rationale that the WG used when this was decided? FWIW, I am very supportive of relatively open IANA policies, but I want to understand why they make sense here.

Isn't it normal for the abstract to precede the boiler-plate?

Support Pete's DISCUSS on this.  

It feels like this document is kind of trying to define a syntax, without actually doing it.  It would make things a lot clearer if you could actually define a concrete syntax, at least at the level of fields.  

Also the AdminKeyName definition is mangled.

One question - in 3. Key Selection and Rollover

      (3)  If an interface is specified, the Interfaces field includes I
      or "all";

This sentence didn't parse for me. Is s/specified, the/specified and the/ what's meant?

Thanks for resolving my discuss.

I've left the comments below but didn't check if there's
more to say or do about 'em. Feel free to ping me if
there is,

S.

--- these were discusses but are now comments

(1) What'd happen if I merge two databases (e.g. if I
buy some new bigger kit that replaces multiple devices)
and the admin key name collides? Should you add a
key-table-name property that should be selected so as
to avoid collisions?

Sam said: 

>> I think you'd want to define how to handle this when defining the merge
>> operation.
>> I can see two approaches that seem likely.
>> First, for environments where the admin key name is not stored in
>> external management systems, just change the name.
>> For systems where an external management system needs to know the admin
>> key name reject the merge until conflicts are resolved (or perform the
>> merge in the external management system).
>>
>> I don't think a key table name would be helpful and it would be
>> confusing as an operator.  If anything I'd expect protocol to partition
>> the table.
>>
>> I've been an operator in situations like you describe and with this
>> style of database I'd prefer to resolve the conflicts than to have yet
>> another database partition.  It's not just lazyness that causes me to
>> think adding the field you propose is the wrong approach; I think it
>> would not add value for the use cases I can see.

I think adding a bit of text about that would be good.

(2) section 2: Having registries for KDFs and AlgIDs
here seems wrong, or maybe I'm confused. Either the
protocol that uses the DB will specify the KDF and
AlgIDs or it will not. If it does, then any such
registry will be part of the protocol itself. If it
does not, then I don't see how I get interop without
having a specificaiton for the input bits to the KDF,
etc which are not always obvious and are not specified
here. Either way, the KDF registry here seems useless
given that there's a registry for the Protocol field.
What am I missing?  

Following mail discussion, I'm ok with that but
have a suggestion:

I think it'd be good to note that there are likely to
be registry entries that overlap with other protocol's
registries. Perhaps it'd be useful to have a column
in this registry that also notes which other protocol(s)
define code points for the entries in this one?



--- original comments below

- section 2: AdminKeyName "by humans" seems wrong, I
think you mean "for humans". The last sentence in this
definition also hides a uniqueness requirement. I agree
with Pete's discuss on i18n here.

- section 2: Is there a bug in the cardinality of
PeerKeyName vs. Peers? It reads as if I can have e.g. 3
Peers for a unicast case and each of those can have
their own local key name, but yet I can only store one
peer key name.

- section 4: this seems a bit vague to me fwiw, I
wondered if someone has actually tried this with a real
key management protocol? (E.g. see my discuss points
about KDFs above)

- Should you say something (e.g. in sections 1 or 7)
about keys that are stored in a HSM? I guess this spec
is really not for those.