Re: [secdir] SecDir review of draft-ietf-hip-rfc6253-bis
Samu Varjonen <Samu.Varjonen@hiit.fi> Fri, 12 February 2016 11:47 UTC
Return-Path: <Samu.Varjonen@hiit.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957711B43FB; Fri, 12 Feb 2016 03:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWkqawAvLDBJ; Fri, 12 Feb 2016 03:47:13 -0800 (PST)
Received: from argo.otaverkko.fi (argo.ipv6.otaverkko.fi [IPv6:2a02:4880:10:1000::2:25]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767171B43F9; Fri, 12 Feb 2016 03:47:13 -0800 (PST)
Received: from webmail.otaverkko.fi (hydra.otaverkko.fi [212.68.0.4]) by argo.otaverkko.fi (Postfix) with ESMTP id 73F89202BB; Fri, 12 Feb 2016 13:47:11 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Fri, 12 Feb 2016 13:47:11 +0200
From: Samu Varjonen <Samu.Varjonen@hiit.fi>
To: Sean Turner <sean@sn3rd.com>
In-Reply-To: <F3AF3182-F31A-4EF8-8DC5-54B27B6ADC05@sn3rd.com>
References: <F3AF3182-F31A-4EF8-8DC5-54B27B6ADC05@sn3rd.com>
Message-ID: <bfbe20ee1196a22eadd854ce7090ffc7@nestor.otaverkko.fi>
X-Sender: Samu.Varjonen@hiit.fi
User-Agent: Roundcube Webmail/1.0.1
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/MLBs0RJuTMGQxU3COAveLaWUUpg>
X-Mailman-Approved-At: Fri, 12 Feb 2016 04:15:32 -0800
Cc: draft-ietf-hip-rfc6253-bis.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [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: Fri, 12 Feb 2016 11:47:15 -0000
Hi, answers inline (and a question). -Samu Varjonen On 22.12.2015 19:22, Sean Turner wrote: > 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. The type number table in the document has been reverted and 2,4,6, and 8 has been obsoleted. > > 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. > We do not support hold and clarification is added > 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? > It will fail with credentials_required error. Clarification added. > 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. > Is this about missing CERT word in the group field? Or did I misunderstand this question? > 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? > The numbers in the Cert ID field MUST start from 1 up to Cert count. Cert ID = 0 would result in INVALID_CERTIFICATE. About the order the document says "The CERT parameters MUST be placed in ascending order, within a HIP control packet, according to their Cert group field." Different order would result in INVALID_CERTIFICATE. Clarification added to the text. > nit 3: Do you need to specify how you do the padding, e.g., all 1s, all > 0s? > All 0s clarified in the text. > 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? > Updated version is added as above. > 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) > Fixed > 3. Might be good to update the validity period :) > Fixed > 4. Are 1024-bit keys normal maybe it should be changed to 2048-bit? > Fixed > 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. > This example's idea is just to show how to include HITs into the certificate so I do not see the reason to add all the possible extensions to it. Unless they could contain HITs. > 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
- [secdir] SecDir review of draft-ietf-hip-rfc6253-… Sean Turner
- Re: [secdir] SecDir review of draft-ietf-hip-rfc6… Samu Varjonen
- Re: [secdir] SecDir review of draft-ietf-hip-rfc6… Sean Turner
- Re: [secdir] SecDir review of draft-ietf-hip-rfc6… Gonzalo Camarillo
- Re: [secdir] SecDir review of draft-ietf-hip-rfc6… Varjonen Samu