Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT)

["STARK, BARBARA H" <[e-mail]>]

Hi Ben,
Thanks a bunch for your comments. I'm sorry it's taken me a few weeks to provide a response. But, well, NomCom... 😊
And I wanted to give these comments the full attention they deserved.
Barbara

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 2 says that the "DTLS certificate values" are required to return
> no value when read, but this property seems to be intended for private
> data such as DTLS private key values, not the certificates themselves
> (which are public).

Thanks. I agree and suggest in Section 2, changing "DTLS certificate values" to 
"DTLS private keys" (which are required to return no value when read).
 
> While I appreciate that IPv6 is the current version of the internet
> protocol, I do see that 6126bis allows for Babel to run over both IPv6
> and IPv4, yet this document in multiple places implicitly assumes that
> Babel runs over IPv6, to the exclusion of IPv4.  Such a restriction from
> the core protocol spec should only be undertaken by an information model
> with clear reasoning and loud disclaimer.

The WG did discuss this and expressed the view that they were only interested
in defining configuration for Babel over IPv6. Note that use of Babel to configure
IPv4 routing tables can be done over IPv6. 

Perhaps if we added to the Abstract <Juliusz: please look at this and provide suggested changes>:
"This information model only includes parameters and parameter values 
useful for managing Babel over IPv6. 
This model has no parameters or values specific to operating Babel
over IPv4, although Babel can be operated over IPv4. 
Note that Babel over IPv6 can be used for configuration of both
IPv4 and IPv6 routes."

and then expand on this in the Introduction with
"This information model only includes parameters and parameter values 
useful for managing Babel over IPv6. 
This model has no parameters or values specific to operating Babel
over IPv4, even though [ID.ietf-babel-rfc6126bis] does define a multicast
group for sending and listening to multicast announcements on IPv4.
There is less likelihood of breakage due to
inconsistent configuration and increased implementation simplicity 
if Babel is operated always and only over IPv6. Running Babel over IPv6 
requires IPv6 at the link layer and does not need advertised prefixes, router
advertisements or DHCPv6 to be present in the network. Link-local IPv6 is widely
supported among devices where Babel is expected to be used.
Note that Babel over IPv6 can be used for configuration of both
IPv4 and IPv6 routes."
 
> Similarly (as Roman notes), we are putting requirements on the key
> length for MAC keys (relative to the block size of the underlying hash
> function) that have were once present in draft-ietf-babel-hmac but have
> been removed as of draft-ietf-babel-hmac-10.  I assume that the intent
> is not to impose additional restrictions compared to the protocol spec,
> thus we need to catch up to those changes.

How humans interact with configuration parameters presented through
a data model instantiation of this information model is a concern. Having 
experienced the horrors of the days of configuring WEP keys (which were 
either ASCII or hex and caused most people not to use WEP with Wi-Fi) 
and witnessed (and been party to) the discussions in
Babel where we wanted to ensure that whatever string was inputted for 
the key would yield consistent MAC computation across all implementations (i.e.,
would yield consistent "actual key"), I believe
it is imperative for the information model to constrain the input. As I explained
in my response to Roman and Valery, we saw considerable variability in
how existing libraries for allowing users to supply a key value treated 
values that could not be directly used as what RFC 2104 calls "the actual key".
To ensure human users are successful in supplying the same "actual key" value to various
implementations, it's necessary for user interfaces to restrict what is
supplied to be "the actual key" so no extraneous hashing and processing
is needed to generate "the actual key" (other than adding zeroes if the input 
key is shorter than an "actual key"). 

The restrictions provided for the length of an input key are consistent with
what the HMAC and BLAKE RFCs indicate for "actual key" length.

This allows implementations of draft-ietf-babel-hmac to use existing HMAC
and BLAKE2s libraries without worrying about what inconsistent manipulations
the libraries or associated libraries for inputting keys do to strings that are
too long to be directly used as "actual keys".

> The description of the babel-mac-key-test and babel-cert-test operations
> need to be tightened up, as the secdir reviewer noted.  (See COMMENT.)

I think the secdir comments from Valery have been resolved.
https://mailarchive.ietf.org/arch/msg/secdir/V_SKLuCuLdwvCDhABW-G2kkgRHM/
https://mailarchive.ietf.org/arch/msg/secdir/_FX7GJpGDhMxBN1Ps0_opo2mn68/
https://mailarchive.ietf.org/arch/msg/secdir/eSC-7ApMvv0CulyawvA0AILB59w/
https://mailarchive.ietf.org/arch/msg/secdir/90YcyVcS90Ya449tT0Zibc6Fb9o/

Summary: Remove babel-cert-test; use "MAC" instead of "hash" in 
babel-mac-key-test description.
Please let me know if you disagree with this resolution.

> We seem to be using terminology from the Network Management Datastore
> Architecture without reference or otherwise introducing the concepts.
> This is a Discuss point because the only candidate reference I know of,
> RFC 8342, is specific to YANG and data models, so it's applicability for
> use in an information model may be subject to discussion.  (Hopefully
> this only reflects my ignorance and not a fundamental lack of datastore
> architecture for information models.)

I'm still a YANG novice. My experience is with BBF TR-181 data models.
I do have a TR-181 data model of this info model that will be published
after the info model is published. I also considered the UIs created by the
Babel protocol implementers to effectively be implementations of the info
model. But of these, YANG does appear to be unique in maintaining distinct
representation of operational and running configuration datastores.
In researching the terminology 
(see https://mailarchive.ietf.org/arch/msg/babel/Ze2EtZEidcE7t2WMF2EqblBJN7I/
reply to Robert Wilton),
it appears to me that "operational datastore" and "datastore" are terms of art defined
in techopedia.com without reference to YANG. The dates on those definitions is 2013,
which predates RFC8342. "Running datastore" was used in RFC6241, which also 
predates RFC8342. As I mentioned in my reply to Robert Wilton, 
I don't think a normative reference to RFC 8342 is appropriate for what appear to be
terms of art. There is no terminology section in the babel-information-model
draft, and I'm not keen on adding a terminology 
section to the draft just for these 2 terms of art.
But I would do that (and maybe find a few other terms of art to include
so they don't seem out of place), if people really felt it necessary to define these.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1.1
> 
> Please use the specific RFC 8174 boilerplate (in particular, it includes
> "NOT RECOMMENDED").

Thanks. I'll make that change. (This was also a comment from Barry.)
 
> Section 2
> 
> We have separate MAC/DTLS-enablement nodes at a per-interface
> level, so not having them at the global level is perhaps suprising.

This was discussed, IIRC, and the WG wanted it at the per-interface
level only. In addition to the YANG and TR-181 data models, I 
considered the implementation user interfaces to also be instantiations
of this information model. So many decisions were made based on what
they found reasonable when implementing their UIs.

> I'm happy to see babel-dtls-cert-types, given that the babel/DTLS spec
> leaves much open as to how to authenticate peers.  Even more specificity
> could be useful.
> 
>    Most parameters are read-only.  Following is a descriptive list of
>    the parameters that are not required to be read-only:
> 
> It's suprising to not see router-id on this list; 6126bis says only that
> "every Babel speaker is assigned a router-id" without saying how.  In
> the absence of a "how", it seems reasonable to assume "assigned by the
> administrator" as a valid option.

The WG discussed this. There are two points here. First is that the self-router-id
is useful as a unique key in YANG. But in that case, the value needs to exist and be 
immutable when the Babel object is created in the system. Second is that
Babel users do not care about the value of the router-id; therefore it's
easiest simply to auto-generate it.

> How do I configure which prefixes to advertise as originated from this
> router?  Do I just add something to the babel-routes list with NULL
> received metric?  But if that's how I do it, then the babel-route-obj
> can't be 'ro'...

Section 3.7 of draft-ietf-babel-rfc6126bis indicates that a Babel 
implementation has the ability to advertise and provide updates
for routes injected into the Babel domain by the local node. I 
believe the Babel implementation interacts with the device's
"real" routing table to identify these routes (and to update
that routing table). Since this is all handled by the implementation
without user interaction, perhaps Juliusz could better explain,
if necessary.

>    o  Interface: Metric algorithm
> 
>    o  Interface: Split horizon
> 
>    o  Interface: enable/disable Babel on this interface
>    [...]
> 
> It might be useful to list these in the same order as they appear in the
> tree diagram.

Thanks. I will put them in the same order as in the object definition
(which is the same as the tree diagram, but the object definition is
normative if there were to be a difference).
 
>    o  Interface: MAC algorithm
> 
> What node in the tree does this correspond to?

Thanks. I'll delete "  o  Interface: MAC algorithm". 
It's an unfortunate vestige of earlier revisions.

> Section 3.1
> 
>    babel-enable:  When written, it configures whether the protocol
>       should be enabled (true) or disabled (false).  A read from the
>       running or intended datastore indicates the configured
>       administrative value of whether the protocol is enabled (true) or
>       not (false).  A read from the operational datastore indicates
> 
> Perhaps it's just me, but running/intended/operational datastores feels
> like a YANG/NMDA thing and is surprising to see in a nominally generic
> information model, absent further reference.
> (Similarly for subsequent usage of the terms.)

This was language we added as a comment from Mahesh to make his
creation of the YANG model straightforward. It's not inconsistent with TR-181
concepts. But this is an area where TR-181 and YANG do things a little
differently. Language compromise was necessary. I will rely on Mahesh
to take a first stab at proposing any changes, and will simply make sure
what I need for TR-181 is still there. I do recommend against a NMDA
reference, since my research suggests these are terms of art.

>    babel-self-router-id:  The router-id used by this instance of the
>       Babel protocol to identify itself.  [I-D.ietf-babel-rfc6126bis]
>       describes this as an arbitrary string of 8 octets.  The router-id
>       value MUST NOT consist of all zeroes or all ones.
> 
> Why is the MUST NOT a requirement of the information model rather than
> the protocol?

Because it isn't an issue for a Babel implementation that doesn't implement
this information model. It only became an issue when the YANG model
needed to use this as a unique key and needed the object to exist whether
or not Babel was enabled. In the absence of YANG, a disabled implementation 
is happy for its router-id to be all zeroes.

>    babel-metric-comp-algorithms:  List of supported cost computation
>       algorithms.  Possible values include "2-out-of-3", and "ETX". "2-
>       out-of-3" is described in [I-D.ietf-babel-rfc6126bis], section
>       A.2.1.  "ETX" is described in [I-D.ietf-babel-rfc6126bis], section
>       A.2.2.
> 
> Perhaps this is just me, but the way this is written implies that the
> specific string values are to be used, which may be overly prescriptive
> for an information model.  Also, is there a registry for these
> algorithms that could be referenced?

There is not a registry. The algorithms an implementation supports
do not impact interoperability of Babel. Therefore, there is no need
for a Babel implementation to only use algorithms from some registered
list. Which makes a registry unnecessary. If an implementation supports 
these algorithms loosely described in
ietf-babel-rfc6126bis, then using these strings to identify them
will make that clear to a user (which is good for usability). It's not 
required for a data model to use these exact strings (a human is unlikely
to be confused by an implementation that uses "2 out of 3" instead of
"2-out-of-3", but, not surprisingly, 
both the YANG and TR-181 data models are using these exact strings.

>    babel-security-supported:  List of supported security mechanisms.
>       Possible values include "MAC" and "DTLS".
> 
>    babel-mac-algorithms:  List of supported MAC computation algorithms.
>       Possible values include "HMAC-SHA256", "BLAKE2s".
> 
>    babel-dtls-cert-types:  List of supported DTLS certificate types.
>       Possible values include "X.509" and "RawPublicKey".
> 
> Likewise, are there registries for these?  (D)TLS does have an existing
> certificate types registry
> (<url munged by email system>
> is the one to use), but for the MAC algorithms that's pretty inherently
> a very flexible extension point so it's easy to add a new algorithm with
> no or a very minimal written spec.

Per other commenters, I will be adding references to these to 
draft-ietf-babel-hmac and draft-ietf-babel-dtls.
The babel hmac draft has normative language for the two mentioned.
The babel-dtls draft inherits from DTLS, which inherits from TLS
"The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise"
-- so there's an expectation that X.509(v3) certs will be commonly supported. 
babel-dtls also explicitly mentions that raw public keys "can" be supported.
The MAC algorithms and types of certificates supported are determined by
by the implementations of babel-hmac and babel-dtls. Those implementations
will need to expose to the data model (by some sort of API, most likely) which
are supported. The values used may be the values exposed, or they may be mapped
from exposed values to values used by the data model. The information model
cannot constrain values exposed to it by APIs.
The problem with using the TLS Certificate Types registry names is several of the names
have spaces, which makes them unusable in TR-181. It's not required for 
an instantiation of this info model to use these "possible" values; but, again, both the
YANG and TR-181 do. By listing them this way (as possible values, not using
normative language), we achieve consistency where
it makes sense and is useful without preventing deviation in some case where
it may not be useful or make sense.

> Section 3.2
> 
>    babel-mcast-group:  Multicast group for sending and listening to
>       multicast announcements on IPv6.  Default is ff02::1:6.  An
> 
> IIRC the core protocol only has it as RECOMMENDED for control traffic to
> be over IPv6; the "on IPv6" here seems unnecessarily limiting.

This was what the WG wanted but is related to your 2nd DISCUSS item (and
my proposed resolution to that).

> Section 3.3
> 
>    babel-interface-reference:  Reference to an interface object that can
>       be used to send and receive IPv6 packets, as defined by the data
> 
> [again the implicit IPv6 requirement]
> 
>    babel-mcast-hello-interval:  The current interval in use for
>       multicast Hellos sent on this interface.  Units are centiseconds.
>       This is a 16-bit unsigned integer.
> 
> Perhaps it is better to discuss that the units need to have sufficient
> precision to represent centisecond granularity rather than to enforce a
> specific unit and constrain data models/implementations.
> (Similarly for other mentions of units.)

This value is the exact value sent via the protocol. The centisecond unit 
of the sent value is specified in draft-ietf-babel-rfc6126bis. I believe it 
would be a bad idea to manipulate the sent value so it is presented to users
with a unit different from the unit of the sent value. Having the info
model provide flexibility that does not exist in the Babel protocol would
add unnecessary complexity and cause potential confusion.
 
>    babel-dtls-cached-info:  Indicates whether the cached_info extension
>       is included in ClientHello and ServerHello packets.  The extension
> 
> Please reference RFC 7924 here.

I would prefer to reference draft-ietf-babel-dtls, which in turn references
RFC7924, because draft-ietf-babel-dtls describes allowed use of this extension.

>       is included if the value is "true".  An implementation MAY choose
>       to expose this parameter as read-only ("ro").
> 
> I wonder if we can/should give a bit more guidance on what to include in
> the extension, as currently it would be compliant with this spec (but
> not very useful) to emit a cached_information extension that is highly
> unlikely to result in any packet size savings.

Possible use of this extension is described in draft-ietf-babel-dtls Appendix A.
I don't think the information model is the appropriate place to provide
implementation guidance for this extension. draft-ietf-babel-dtls would
be the correct place for any additional implementation guidance. I think
draft-ietf-babel-dtls is currently in the RFC Editor's queue.

>    babel-dtls-cert-prefer:  List of supported certificate types, in
>       order of preference.  The values MUST be among those listed in the
>       babel-dtls-cert-types parameter.  This list is used to populate
>       the server_certificate_type extension in a Client Hello.  Values
> 
> An RFC 7250 reference is probably in order.

I would prefer to have a reference to draft-ietf-babel-dtls. That is
where the certificate types for a Babel DTLS implementation are 
discussed. draft-ietf-babel-dtls does reference RFC7250. An
understanding of RFC7250 is not necessary for implementing
this information model or any data model derived from it.

>    babel-packet-log:  A reference or url link to a file that contains a
>       timestamped log of packets received and sent on babel-udp-port on
>       this interface.  The [libpcap] file format with .pcap file
>       extension SHOULD be supported for packet log files.  Logging is
> 
> Does there need to be a mechanism for content-type
> negotiation/indication?

The format for this optional log was discussed by the WG. After
considering a variety of ways to proceed, this was the agreed outcome.
Adding content type negotiation would add unnecessary complexity,
since it's unlikely that an implementation would support more than one
content type.

> Section 3.4
> 
> Shouldn't these all be 'counter's, not 'uint's?

Hmm. Interesting.
It looks like I introduced "counter" as a (potential) base type in the -01
draft (when I was sole author and there were no statistics yet defined). I
just took all the data types in RFC8193 that looked like they might prove 
useful at some point.
It appears to be a vestige of that early draft stage that never got used.
uint is perfectly suitable from an info model perspective. Of course,
a data model can use a more specific datatype derived from uint, that
is specially designed for counted statistics.
I suggest deleting the "counter" data type, but will check with Mahesh 
just to be safe.

> Section 3.5
> 
>    babel-hello-mcast-history:  The multicast Hello history of whether or
>       not the multicast Hello packets prior to babel-exp-mcast-hello-
>       seqno were received.  A binary sequence where the most recently
>       received Hello is expressed as a "1" placed in the left-most bit,
> 
> This seems to indicate that the leftmost bit is always '1', and thus
> that we cannot be in a situation where we missed one expected multicast
> hello and are already expecting "the one after it".  Is that correct?

Yes. An implementation won't know it has missed one until it receives a Hello 
with a non-sequential sequence number. The number of missed packets 
is derived from the difference between the sequence numbers of 2 received 
packets. One of the implementations provided the history in this manner and
found it to be a very simple way to present this information. It proved useful
as a diagnostics tool. So the WG agreed to put it in the info model as an 
optional element.
 
> Also, should we say anything about truncating the bitstring at some
> arbitrary point?
> 
> (Similarly for the unicast case, on both counts.)

This was discussed by the WG. The implementation that provided the 
history in this manner used 16 bits. But it was decided not to constrain
a data model or implementation that might want to allow more bits to be 
stored. So the maximum number of history bits stored is left up to the 
data model and the implementation.

>    babel-exp-ucast-hello-seqno:  Expected unicast Hello sequence number
>       of next Hello to be received from this neighbor.  If unicast Hello
>       packets are not expected, or processing of unicast packets is not
>       enabled, this MUST be NULL.  This is a 16-bit unsigned integer; if
> 
> (We haven't defined "NULL" semantics yet.)

I'm unclear as to what sort of semantics are needed? In discussing this
verbiage in the context of terminology that would work for TR-181 and 
YANG, we figured out we needed to ensure there was a distinction between
seqno of all zeroes (an allowed value) and no reception/expectation of 
unicast packets. How this is done in YANG and TR-181 is very different.
So it's important not to over-define the semantics of "NULL".
 
> Section 3.6
> 
>    babel-route-neighbor:  Reference to the babel-neighbors entry for the
>       neighbor that advertised this route.
> 
> Wouldn't that make this a "reference" type rather than "string"?

Yes. I'll make that change. Thx.
 
>    babel-route-seqno:  The sequence number with which this route was
>       advertised.  This is a 16-bit unsigned integer.
> 
> Is this text correct for locally originated routes?

Yes. The babel-route-obj allows read-only access to useful parts of the Babel 
"Routing Table" described in draft-ietf-babel-rfc6126bis. Parameters that an 
implementation includes in the Babel "Routing Table" are defined there. This 
Babel "Routing Table" must not be confused with a device's routing table
that would be maintained external to a Babel implementation.
 
> Section 3.7
> 
> I don't wish to revisit the decision, but it might have been interesting
> to record some of the reasoning for having an additional abstraction for
> "key set" and having a list of key-sets, vs just having a list of keys
> directly.  (Similarly for the DTLS cert sets.)

There were requirements that it be possible to use different keys for
different interfaces, the same keys for a set of interfaces, the same
keys for all interfaces, and have a default set of keys in case a new
interface were instantiated (e.g., a tunneled interface). Also, there
was a requirement that it be easy to change the current key by first
adding the new key and then removing the old key. By having key sets,
it was easy to do a key change without explicitly adding the new
key to and deleting the old key from each impacted interface. Only
the key set needed to be updated. Ditto for certs. If this explanation is
useful, I could add a paragraph explaining the sets as useful in making
it easy to change keys/certs to Security Considerations. Ensuring usability 
of key/cert change is, I think, a valid security consideration.
 
> Section 3.8
> 
>    babel-mac-key-use-sign:  Indicates whether this key value is used to
>       sign sent Babel packets.  Sent packets are signed using this key
>       if the value is "true".  If the value is "false", this key is not
> 
> I agree with the secdir reviewer that the "sign" terminology is
> problematic here, and would prefer something like
> "babel-mac-key-use-generate" and a similar wording in the prose.

In email exchange with Valery, it was agreed to rename this to
babel-mac-key-use-send.

>    babel-mac-key-value:  The value of the MAC key.  An implementation
>       MUST NOT allow this parameter to be read.  This can be done by
>       always providing an empty string when read, or through
>       permissions, or other means.  This value MUST be provided when
>       this instance is created, and is not subsequently writable.  This
>       value is of a length suitable for the associated babel-mac-key-
>       algorithm.  If the algorithm is based on the HMAC construction
>       [RFC2104], the length MUST be between 0 and the block size of the
>       underlying hash inclusive (where "HMAC-SHA256" block size is 64
>       bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s",
>       the length MUST be between 0 and 32 bytes inclusive, as described
>       in [RFC7693].
> 
> [Per the Discuss, this key-length guidance is not aligned with
> draft-ietf-babel-hmac.]

I defer to my explanation above (under the DISCUSS).
 
>    babel-mac-key-test:  An operation that allows the MAC key and hash
>       algorithm to be tested to see if they produce an expected outcome.
>       Input to this operation is a binary string.  The implementation is
>       expected to create a hash of this string using the babel-mac-key-
>       value and the babel-mac-key-algorithm.  The output of this
>       operation is the resulting hash, as a binary string.
> 
> s/create a hash of/create a MAC over/
> s/resulting hash/resulting MAC value/

Thx. Will do.

> Given that the intent is to test the MAC operation, it seems like we
> might want to say that the input string is treated as a babel packet,
> getting the pseudo-header added per draft-ietf-babel-hmac §4.1, etc.
> It would be in keeping with cryptographic best practice to continue to
> use the same pseudo-header (and possibly even include a disambiguating
> context string) to avoid the risk of being an oracle for generating the
> MAC of arbitrary text that could then be used to forge other packets
> elsewhere.

Since the entity that can use the test can also directly set the key, I'm not
sure of the use case for an entity with management permissions to
perform such an attack. But I agree that the test could easily be made
more secure, so it's a good idea to do so. I've thought about your suggestion 
of treating the input string as a babel packet; but I think that gets very
complicated because of the behaviors around packet counters and index and
generation of pseudo headers (the management interface IP addresses and
ports may be unknown to a Babel implementation and including IP headers in
this test string makes it even more complicated). So the same code couldn't 
really be used). 
What if we had 2 inputs: the binary string and the expected MAC? 
Then the output would just be success (input expected 
MAC = calculated MAC) or failure. Would something like this be better?
Alternately (though I would prefer it less), we could have the input string
just be the expected MAC, where the binary string to generate a MAC for
would be defined here. The string could be something simple like 
the concatenation of the registered Babel multicast group (ff02::1:6) 
and UDP port (6696).
 
> As the secdir review noted, the MAC output length is not necessarily
> fixed by the algorithm, so some indicatino of the output length is also
> in order.

The WG has discussed making 128 bits recommended for BLAKE2s 
(change will be made in AUTH48 to draft-ietf-babel-hmac) and
the corresponding possible configuration value in this model will be
"BLAKE2s-128". 

> Section 3.10
> 
>    babel-cert-name:  A unique name for this DTLS certificate that can be
>       used to identify the certificate in this object instance, since
>       the value is too long to be useful for identification.  This value
> 
> Some guidance on whether or not it is expected to be useful to draw
> naming information from the certificate's Subject information, vs an
> arbitrary or fingerprint-based naming scheme, might be in order.

All constraints from an info model perspective are provided in the 
description: unique and not empty. An implementation that supports 
auto-generation of the name can use whatever rules it wants. 
My TR-181 data model will allow the user to provide any unique and
non-empty string they want. If the user provides none, the
auto-generation scheme is implementation-specific and common 
across the entire TR-181 data model (and not just Babel). I think it 
would be odd to explicitly call out the absence of additional requirements
or expectations. Unless pressed, I will make no change here.

> Also, it's somewhat unusual to talk about "(D)TLS certificates" as
> opposed to X.509 certificate, raw public key, etc..

The TLS RFCs refer to these things as "certificates" in all cases, and
the IANA registry that lists defined types of these things is titled 
"TLS Certificate Types". This info model table is defined so it should be 
possible for other certificate types to be supported (if desired or
implemented) with no change to this table structure -- so long as 
the certificate can be expressed in PEM format. If "DTLS certificate"
is not acceptable, I could change to just "certificate". I don't want
to constrain what type of certificate this table can support, beyond 
PEM format and for use with an implementation of draft-ietf-babel-dtls.
 
>    babel-cert-test:  An operation that allows a hash of the provided
>       input string to be created using the certificate public key and
>       the SHA-256 hash algorithm.  Input to this operation is a binary
>       string.  The output of this operation is the resulting hash, as a
>       binary string.
> 
> This is problematic in several ways, as noted by the secdir reviewer.
> For one, if we want to test a certificate, we usually would do that by
> producing a signature, not a hash over the public key and some other
> input.  Furthermore, not all the signatures produced by X.509 certificates
> compatible with DTLS require a hash at all or are allowed to use SHA-256
> within the signature operation.  It may be possible to require SHA-256
> always by having the input to the signature operation be the SHA-256
> output, which would then be hashed again during the process of computing
> an (e.g., RSA) signature, but that is also a bit weird.
> The purpose of the operation needs to be made more clear (is it to
> verify the public key?  The private key?) as well as how the input is
> structured; if the certificate private key is used to generate a
> signature we must take care to avoid producing a signing oracle that can
> be used to produce signatures valid in other contexts.

It was agreed (with Valery) to delete this operation.

> Section 5
> 
> We do expose an operation to get a packet dump, but it's not clear that
> there are particularly noteworthy security considerations regarding that
> -- the dump would appear to be the ciphertext based on the language
> used, so it would not be a way to bypass DTLS encryption, for example.
> 
>    This information model defines objects that can allow credentials
>    (for this device, for trusted devices, and for trusted certificate
>    authorities) to be added and deleted.  Public keys may be exposed
>    through this model.  This model requires that private keys never be
> 
> It might be worth another sentence indicating the scale of the
> consequences of erroneously/maliciously setting such credentials.

I'm not quite sure what to say? "Incorrect configuration of credentials
(whether in error or in malice) will cause the Babel packets between
the incorrectly configured router(s) and other routers in the network
not to be trusted by each other. It will not be possible to effectively
use Babel to determine and react to routing changes in the network, 
in this case."
 
>    exposed.  The Babel security mechanisms that make use of these
>    credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac])
>    identify what credentials can be used with those mechanisms.
> 
> The DTLS one really doesn't, though -- it says only something like
> "details of identity management are left to deployment profiles", and
> there's a wide variety of DTLS credentials that are possible.
> The MAC mechanism has a much clearer picture about what is allowed by
> virtue of using the raw crypto primitive (though the allowed MAC
> algorithms are negotiated out-of-band there as well).

Perhaps: "The keys used by a [ID:ietf-babel-hmac] implementation are
modeled as private keys. Certificates used by a [I-D.ietf-babel-dtls]
implementations use separate parameters to model the public parts
(including the public key) and the private key."

>    algorithm associated with the key.  Short (and zero-length) keys and
>    keys that make use of only alphanumeric characters are highly
>    susceptible to brute force attacks.
> 
> I don't think it's true to say that "keys that make use of only
> alphanumeric characters are highly susceptible to brute force attacks".
> Even if I stick to a 32-byte key, `dd if=/dev/random bs=1
> count=24|openssl base64` is giving me 192 bits of randomness, which is
> plenty for a modern security protocol.  I think you mean to say that
> short keys are especially susceptible to brute-force when they only use
> alphanumeric characters.

Perhaps simplify this to: "Short (and zero-length) keys are highly
   susceptible to brute force attacks."

> Section 8.2
> 
> Per
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ even
> optional features like DTLS, MAC, RFC 3339 timestasmps, etc., should be
> listed as normative references.

Thx. I'll be moving the following references from informative to normative:
[I-D.ietf-babel-dtls]
[I-D.ietf-babel-hmac]
[ISO.10646] (Unicode character definition)
[RFC2104] (HMAC)
[RFC3339] (Timestamps)
[RFC4868] (HMAC-SHA-256)
[RFC7693] (BLAKE2s)