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

Sean Turner <sean@sn3rd.com> Tue, 22 December 2015 17:22 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F81A6FC8 for <secdir@ietfa.amsl.com>; Tue, 22 Dec 2015 09:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.102
X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gL5vh5tQLrL1 for <secdir@ietfa.amsl.com>; Tue, 22 Dec 2015 09:22:46 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9168D1A0275 for <secdir@ietf.org>; Tue, 22 Dec 2015 09:22:46 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id o11so59283833qge.2 for <secdir@ietf.org>; Tue, 22 Dec 2015 09:22:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=8IQLl7fr2uvrjB4cGFksJrYfNSBLRcKRf/tS4U9M9jQ=; b=gTCoxok+iMvgmvyffR0GWvez+gLRZrcp/gS6eOApZy6C86uBDniM8SKl3mDLnx1fMM r8Dvf9bP33NSXu8Q72NRcb8G6lQlBV1mqZj3+RkH7ncOliFH7sLVE7x2n0BSWOqOpD0R 9rhGy/AbFF0ZcjGsqnqk0bfNYQ2bBy3JHvOUs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=8IQLl7fr2uvrjB4cGFksJrYfNSBLRcKRf/tS4U9M9jQ=; b=DspquL8rxIYbdoi59ym+0Y1AFsqJ8c/1LC11Jmc/4YAZ++HgM7CzLqjF+m77sKpyXp pUOYqmifCr8BT0YaIW2Y3Xi0QYTEL1ZZYIf2hXR8NNwbe4Sn6fy+2/i75w2SAffVP2/b 30fyf5GkKnA4Ep5p60zN0qxXe2m1NjPQp/BVIVAAlU+oVDcwKnkzeu78Bc4nHEPZV2bS MrC6sO3uCYH9Z6vP/oNe7qrVKl3RMxSOJWw5Htx/oh+eyNU4KAGcoTy9G4mZM5Qo+LiE pYep783JtRy2W91BFsTUBMvvZ67USP9PWNgBY57k5hjvSXvqG1yXYBvSJhcCe3R3f54Y DnxA==
X-Gm-Message-State: ALoCoQk1aRPUEee/f2r4/fldyELIy1FMrLQPSI5mlMhrHW6ie2Uwkrrz/m0d99xr+larh9ko6xoY38iPciqBvLwi/TZqLDO5bQ==
X-Received: by with SMTP id 8mr35227706qhm.60.1450804965770; Tue, 22 Dec 2015 09:22:45 -0800 (PST)
Received: from [] (pool-173-73-126-234.washdc.east.verizon.net. []) by smtp.gmail.com with ESMTPSA id l124sm16326705qhc.24.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Dec 2015 09:22:44 -0800 (PST)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3AF3182-F31A-4EF8-8DC5-54B27B6ADC05@sn3rd.com>
Date: Tue, 22 Dec 2015 12:22:43 -0500
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-hip-rfc6253-bis.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/vXPKHnSc6j9rHbsO3Qhu1O0edlc>
Subject: [secdir] SecDir review of draft-ietf-hip-rfc6253-bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2015 17:22:48 -0000

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:


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?


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?