Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-07

[Sam Hartman <[e-mail]>]

>>>>> "David" == Black, David <[e-mail]> writes:

    David> Document: draft-ietf-karp-crypto-key-table-07 Reviewer: David
    David> L. Black Review Date: April 25, 2013 IETF LC End Date: April
    David> 29, 2013

    David> (Section 2)

    David> [1] LocalKeyName and PeerKeyName are strings.  What character
    David> set?  If Unicode (e.g., UTF-8?), add text on Unicode
    David> considerations (e.g., normalization).  Finding a Unicode
    David> expert will help in getting this done quickly.  I have
    David> similar concerns for other strings, and in particular, IANA
    David> should be told what a "string" is for any registry field that
    David> contains one.
Proposed fix;
The LocalKeyName field contains a string identifying the
key. It can be used to retrieve the key in the local database when
received in a packet.  As discussed in Section 4,  the protocol
defines  the form of this field. For example, many routing protocols
restrict the format of their key names to integers that can be
represented in 16 or 32 bits. Typically this field does not contain
data in human character sets requiring internationalization.
If there ever are any Protocols with key names requiring
internationalization, those specifications MUST address
issues of canonicalization and normalization so that key names can be
compared using binary comparison.

    David> [2] I'm not sure that I understand what a KDF really is from
    David> its high level description in this draft.  At the least, I'm
    David> surprised that the importance of non-invertibility of a KDF
    David> is not mentioned - beyond that, a functional description of
    David> inputs and outputs would help, including a strong
    David> recommendation to inject unpredictable nonce material.  This
    David> could be handled by referencing material on what a KDF is
    David> that exists elsewhere.
The KDF field indicates the key derivation function which is used to
generate short-lived keys from the long-lived value in the Key field.
When the long-lived value in the Key field is intended for direct use,
the KDF field is set to "none".  A key derivation function is a
one-way function that provides cryptographic separation of key
material.  The KDF MAY use inputs from the row in the key table and
the packet being sent or received but MUST NOT depend on other
configuration state.

    David> (Section 4)

    David> [3] It's important that this section cover all the fields
    David> involved in the database lookups in Section 3 whose format
    David> may be protocol-specific (the Direction and various time
    David> fields aren't).  Protocol should be covered by the IANA
    David> registry, peers and key names are covered here, but interface
    David> appears to be missing - item (9) covers presence vs.  absence
    David> of interface information, but not its format.
The form of the interfaces field is not protocol-specific but instead
is shared among all protocols on an implementation.  If a protocol
needs to distinguish instances running over the same interface, this
is included in the specification of peers.  Generally it is desirable
to define the specification of peers so that an operator can use the
interfaces field to refer to all instances of a protocol on a link
without having to specify both generic interfaces information and
protocol-specific peer information.

    David> --- Lots of issues with the IANA Considerations (Section 8)

I could really use some help from one of the other authors resolving the
IANA issues.
I've made the trivial fix of getting info vs values consistent.

    David> [7] Should some sort of formats for Peers and Interfaces be
    David> included in registering a Protocol?  If not, the lookups in
    David> section 3 may be implementation-dependent (strings that work
    David> w/one implementation may not work w/other implementations of
    David> the same protocol).  The specification reference may suffice
    David> based on the requirements in section 4 for what has to be in
    David> each referenced specification.

I think section 4 should  handle this.
We could add a bit of text reminding people that the specification needs
to address the issues brought up in section 4.


    David> [9] I suggest Expert Review for these registries, not just
    David> First Come First Served, so that someone with a security
    David> "clue" can check that the proposed registrations are
    David> reasonable.

I don't think I've seen support for this on the WG list.

    David> Minor issues:


I don't think it does even conceptually.
It's much closer to the SPD.
However there are no plans I'm aware of to use this to configure IPsec
and I think several of us might push back against that.

    David> [B] (Section 2) Where is key size recorded?  Is that an
    David> implicit attribute of Key?

yes.

    David> [C] (Section 3) Where does key selection occur?  I would
    David> suggest that the database return all possible keys and let
    David> the protocol figure out what to use.  This is particularly
    David> important for inbound traffic for obvious reasons.

No, the hope is that the key selection can be shared among protocols;
that's one of the main things that you get out of something like this.
The intent is that the protocol passes the things described in section 3
into the key table which pops out the right row.

We think this is solid for received packets; if you think we've missed
something please let us know: much easier to fix now!