[secdir] SecDir review of draft-ietf-hip-rfc6253-bis

[Sean Turner <[e-mail]>]

Fear not as this is just the secdir review!

I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

draft summary: This is a bis document that specifies the certificate parameter and the error signaling in case of a failed verification for the Host Identity Protocol (HIP) v2; the previous version was experimental now it's moving to the standards track.  The big change is that the SPKI cert type got dropped.

secdir summary: pretty darn close to being ready, but I’ve got a couple of questions and some nits:

Questions:

Q1. What’s the rationale for the renumbering of the certificate types?  Were there no HIPv1 implementations that used the SPKI option so it’s safe to just renumber?  If you’re not 100% sure whether there were any you could mark values 2, 4, 6, and 8 as reserved/obsoleted and keep on using the existing values for 3, 5, 7.  nit-wise: In s2 values 5-8 are still referenced in the last three paragraphs.

Q2. I see that you pointed from s4 to s5 of 5280 for revocation.  The only error signaling in your s5 seems to be “invalid", but 5280 defines a number of CRL reason codes, e.g., key compromise, but also “hold”.  If you’re not planning on supporting “hold” then it might be worth adding some more text to say that any HIP certificate serial number that appears on the CRL is treated as “invalid” regardless of the reason code.  BTW - I’m in no way suggesting that you support hold.

Q3. On the errors, does the credential_required error cover the case where the sender's cert is sent but not the intermediary?  I’m assuming short paths, i.e., root, intermediary, and end-entity, so you’d just send the end-entity and the recipient says “hey send me you’re intermediary” or does it just fail with the credentials_required error?

Nits:

nit 0: Often a bis draft will include a section that says what’s changed since the original draft, but since it’s basically just “we dropped the SPKI certificate type” maybe just put something like that at the end of the introduction?

nit 1: I read this a couple of times:

  CERT parameters with the same Cert group number
  in the group field indicate a logical grouping.

Isn’t it that the same group # is in the Cert group field:?

  CERT parameters with the same number
  in the Cert group field indicate a logical grouping.

nit 2: There’s some error signaling, but what happens if I set Cert ID to 0, the CERT parameters are not sent in ascending order, etc. do you throw an error?

nit 3: Do you need to specify how you do the padding, e.g., all 1s, all 0s?

nit 4: About the example cert in Appendix A:

0. It’s not really a certificate in Appendix A it’s a pretty print of some certificate fields.  Maybe you could include the HEX representation of DER cert in section A.1 and the pretty print in section A.2?

1. The example shows sha1WithRSAEncryption and that’s not one of the algs in RFC 7401; switch it to ecdsa-with-SHA384 or whatever is being used most now.

2. The serial # can’t be 0 it’s got to be a positive # (see s4.1.2.2 of 5280)

3. Might be good to update the validity period :)

4. Are 1024-bit keys normal maybe it should be changed to 2048-bit?

5. I get that there will be profiles for the HIP certificates, but there’s a couple of extensions not shown that are in pretty much every certificate compliant with RFC 5280; AKI and KU come to mind.

A question that I’m curious about but that has absolutely nothing to do with whether this draft progressing or not (i.e., IESG these are not the droids you’re looking for): Is anybody implementing the DSA suite in RFC 7401?

spt