[babel] babel-dtls: verifying "authentication"

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

I read the draft and think the last paragraph of 2.1 could do with a little more verbiage as to what "fails to verify the peer's authentication" means, since it's part of a "MUST" normative statement. I also don't think the word "authentication" is used consistently or (in some cases) correctly. I think of "authentication" as a process.

I find "request client authentication" and "verify the peer's authentication" to be odd uses of the word "authentication", and not consistent with my understanding of the word. I would suggest something like "request client certificate" (consistent with the name of the message that is sent) or "request client credentials" for the first phrase. And perhaps "validate the peer's certificate" or "validate the peer's credentials" for the second. Unless you mean something different by "verify" vs. "validate" here. 

Will only X.509 certificate keys be allowed, or will "DH_anon" key exchange be allowed? 

Here are the possible things that are sometimes done as part of certificate validation, that I think this phrase is potentially referring to:
1. Ensure the certificate validDate is not in the past. This check should only be done if the implementation thinks the underlying system has acquired a good current time (i.e., it runs a NTP client and getting the current datetime via NTP has succeeded, or the current datetime has been configured). 
2. Check the certificate's chain of trust for a trusted CA. This would mean there is a configured set of trusted CAs.
3. Check if the certificate has been revoked. This is often not done, but might not be a bad idea the first time the certificate is seen.
4. Check if this identical certificate is included in a store of trusted certificates (either it was previously trusted and stored or the store is configured).
5. Check some aspect of "identity". Is there some characteristic of the peer that is expected to be stable wrt a certificate? For example, would the same certificate always originate from the same MAC address or LL IPv6 address? 
6. If a TOFU (trust on first use) policy is supported, what exactly should be trusted (and what should not be trusted)? I do like allowing for a TOFU policy (if an implementation chooses to support one). If it is allowed, I would suggest something like the cert is TOFU if the IPv6 LL address hasn't been seen before (new neighbor). After that it always has to use the same cert. When changing certs, send old and new cert together for some time, so new cert is associated with trusted old cert.

Presumably, a device might be configured with a new certificate at some point (like when the old one expires). Will the new certificate be considered the same neighbor if the "identity" matches (see item 5 for question on determining identity)? If you get a request for a new DTLS session and already have a session for that "identity" (IPv6 LL address?) with a different certificate, what do you do?

If there is already a DTLS connection using a provided certificate, what do you do if you get a request for a new DTLS session using the same certificate? Tear down the old one?

With all this said. I think it might be enough if the draft had statements like:
"The key exchange mechanism used MUST require use of X.509 certificates." (if this is the intent)
"Certificate validation MUST be done according to internal policy. Characteristics of certificates that MAY be used for validation include the validDate, the Certificate Authority (CA) chain of trust, inclusion in a revocation list, prior determination of trust, and whether the IPv6 link local address is the same as in prior uses of the certificate. A trust on first use (TOFU) model MAY be supported, with policy defined by the implementation. Any TOFU policy MUST, at a minimum, ensure that a given certificate is only ever used from a single IPv6 link local address (neighbor) and fail an unknown certificate used for an IPv6 link local address already associated with a trusted certificate. "
"When new certificates are issued, they SHOULD be sent together with the old certificate prior to the old certificate's expiration or revocation, so it is possible for the new certificate to inherit any trust associated with the old certificate."

Or make certificate validation a SHOULD. ☹
Barbara