Thanks for the quick response - most of your message looks reasonable to me.
I have a few additional comments.
[1] Character set for key names, etc.
They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
That's certainly a reasonable goal, and there are plenty of examples of
protocols that do that. OTOH, when the character set is Unicode, generating
strings for which that binary comparison for equality works as expected has
a number of subtleties when the strings are input by humans. Pete Resnick
and yours truly are among the people familiar with the "dragons" that lurk
here (and the precis WG is grappling with).
We needed to add the entire complexity of making these fields be strings
not integers because of some non-IETF protocols that use key names.
I'm reasonably confident I can sell Pete on the concept of a binary
identifier for this field from an i18n standpoint.
I have no problem with the field being a binary identifier, but I think
implementers should be put on notice that binary comparison of human input
Unicode strings doesn't work as expected unless some things are done to
make it work (this used to be known as string preparation). A warning
to that effect, perhaps citing a reference for details on what can go awry,
accompanied by making the protocol spec responsible for getting this right
ought to suffice.
[3] Protocol responsibility to specify interface format
We
mandate that you must be able to tie things to interface. However the
format of an interface is quite specific to the routing platform in
question.
Ok, I suggest explaining that as part of a statement that a protocol cannot
in general be expected to specify interface formats that apply across all
implementations due to implementation diversity.
[7] Additional format information in registry
Black,> [7] Should some sort of formats for Peers and Interfaces be
Black,> included in registering a Protocol? If not, the lookups in
Black,> section 3 may be implementation-dependent (strings that work
Black,> w/one implementation may not work w/other implementations of
Black,> the same protocol). The specification reference may suffice
Black,> based on the requirements in section 4 for what has to be in
Black,> each referenced specification.
When you register a protocol you need to point to a specification that
gives details on this sort of thing.
That makes sense, and section 4's requirements on the specifications
cover this area, but I thought I'd ask.
[9] Registry policy
As an individual, I support FCFS, because I think getting expert
approval for some of the uses that have been proposed for these
registries will be challenging.
The two registries involved are for KDFs and cryptographic algorithm
identifiers.
This feels like something that the security area ought to weigh in on, as it
looks like it includes the "vanity crypto" discussion tarpit ;-). At a minimum,
I would think that there ought to be some means of prohibiting registration
of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13).
Thanks,
--David
-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: Thursday, April 25, 2013 12:47 PM
To: Black, David
Cc: Russ Housley; tim(_dot_)polk(_at_)nist(_dot_)gov;
zhangdacheng(_at_)huawei(_dot_)com; gen-
art(_at_)ietf(_dot_)org; karp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
<stbryant(_at_)cisco(_dot_)com>
Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07
Here are some quick initial responses to your comments.
Thanks much for the review and I'll follow up with more detail in a
while.
"Black," == Black, David <david(_dot_)black(_at_)emc(_dot_)com> writes:
Black,> Major issues:
Black,> (Section 2)
Black,> [1] LocalKeyName and PeerKeyName are strings. What
Black,> character set? If Unicode (e.g., UTF-8?), add text on
Black,> Unicode considerations (e.g., normalization). Finding a
Black,> Unicode expert will help in getting this done quickly. I
Black,> have similar concerns for other strings, and in particular,
Black,> IANA should be told what a "string" is for any registry
Black,> field that contains one.
They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
Character set, to the extent it is specified will be specified by the
individual protocol.
In practice the protocol will say that it's an integer represented as
an ASCII string.
We needed to add the entire complexity of making these fields be strings
not integers because of some non-IETF protocols that use key names.
I'm reasonably confident I can sell Pete on the concept of a binary
identifier for this field from an i18n standpoint.
But issues, of length, format, etc are all specified by the protocol
spec.
Black,> [2] I'm not sure that I understand what a KDF really is from
Black,> its high level description in this draft. At the least, I'm
Black,> surprised that the importance of non-invertibility of a KDF
Black,> is not mentioned - beyond that, a functional description of
Black,> inputs and outputs would help, including a strong
Black,> recommendation to inject unpredictable nonce material. This
Black,> could be handled by referencing material on what a KDF is
Black,> that exists elsewhere.
I'm open to text either proposed on the IETF list from one of the other
authors.
Some protocols have a KDF input some do not.
If they do, it will be drawn from a set of allowable valuable for that
protocol.
Black,> (Section 4)
Black,> [3] It's important that this section cover all the fields
Black,> involved in the database lookups in Section 3 whose format
Black,> may be protocol-specific (the Direction and various time
Black,> fields aren't). Protocol should be covered by the IANA
Black,> registry, peers and key names are covered here, but
Black,> interface appears to be missing - item (9) covers presence
Black,> vs. absence of interface information, but not its format.
The interface is implementation-specific not protocol specific. We
mandate that you must be able to tie things to interface. However the
format of an interface is quite specific to the routing platform in
questino. I don't think there's a way that an IETF document can go into
useful detail on that. SNMP and Netconf have models of how interfaces
are represented. If we ever put together a Netconf schema for this
database, we'd specify the interface there.
Black,> --- Lots of issues with the IANA Considerations (Section 8)
Black,> (Section 8.1.1)
Black,> [5] No field format information for the fields in a registry
Black,> entry. IANA should be told what formats to expect/use.
Thanks, agreed.
Black,> [6] "Protocol Specific Values" is not the same as
Black,> "ProtocolSpecificInfo" in section 2; the same name should be
Black,> used, but whitespace differences are ok.
Good catch.
Black,> [7] Should some sort of formats for Peers and Interfaces be
Black,> included in registering a Protocol? If not, the lookups in
Black,> section 3 may be implementation-dependent (strings that work
Black,> w/one implementation may not work w/other implementations of
Black,> the same protocol). The specification reference may suffice
Black,> based on the requirements in section 4 for what has to be in
Black,> each referenced specification.
When you register a protocol you need to point to a specification that
gives details on this sort of thing.
Black,> (Sections 8.2 and 8.3)
Black,> [8] No registry entry content descriptions. Need to supply
Black,> information on what to register and the formats of the
Black,> elements of a registry entry.
Thanks.
Black,> [9] I suggest Expert Review for these registries, not just
Black,> First Come First Served, so that someone with a security
Black,> "clue" can check that the proposed registrations are
Black,> reasonable.
As an individual, I support FCFS, because I think getting expert
approval for some of the uses that have been proposed for these
registries will be challenging.