[secdir] Secdir review of draft-ietf-sidr-res-certs

Sam Hartman <hartmans-ietf@mit.edu> Thu, 10 March 2011 17:36 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E9FCA3A6992; Thu, 10 Mar 2011 09:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.618
X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id FcdkokaPsiuF; Thu, 10 Mar 2011 09:36:35 -0800 (PST)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org []) by core3.amsl.com (Postfix) with ESMTP id B8D373A691F; Thu, 10 Mar 2011 09:36:35 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D7FEE20265; Thu, 10 Mar 2011 12:35:09 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D780E432D; Thu, 10 Mar 2011 12:37:26 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org, secdir@ietf.org
Date: Thu, 10 Mar 2011 12:37:26 -0500
Message-ID: <tslhbbag9m1.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: draft-ietf-sidr-res-certs@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 10 Mar 2011 17:36:37 -0000

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 primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes a certificate profile for resource certificates
in the RPKI. That is, this is a profile of RFC 5280 that describes
behavior for CAs and RPs in the RPKI with regard to resource

I have one large issue I'd like to call to the IETF's attention; I think
the WG has made an incorrect technical decision and I'd like the IESG
both to review whether they believe that decision is correct and to see
if that decision has sufficient support in the broader security and
routing community.

The basic issue surrounds extensibility and extensions.  The working
group concluded that they want to closely control how resource
certificates are used. To me, that seems like a reasonable decision.
So, they mandate that only a specific set of options from RFC 5280 are
permitted in resource certificates. This is a constraint on the behavior
of CAs. A CA could not for example generate a certificate useful both as
a resource certificate and for a purpose requiring a specific
Again, doing so seems entirely reasonable.

The document also requires that relying parties reject certificates that
include unknown extensions. The rationale explained in section 8 is that
it is undesirable to have a situation where if an RP implemented more
extensions it would reject certificates that a more minimal RP would
In other words the profile picks security and minimalism over

I'm a fan of security, but I believe this decision is misplaced because
I believe it provides the IETF insufficient flexibility to correct
errors or evolve the RPKI in the future.  Remember that CAs are trusted
entities typically within an organization or that you have a contract
with. Examples of CAs in the RPKI include RIRs, your ISP and potentially
a RPKI CA within your organization. We're saying that the possibility
that one of these entities would include an unexpected extension and
cause some harm is worth giving up the mechanisms we'd likely use to fix
problems or deploy additions to the RPKI in a backward compatible

How realistic is it that we would end up finding errors?Well let's take
a look at changes in information managed by the RPKI over the last few
years. The most obvious change I can think of is that we've moved from
16-bit AS numbers to 32-bit AS numbers (or at least we're trying to get
Now it turns out that RFC 3779 handles this correctly and that we don't
have a problem in this area. It's also likely given that RFC 3779 uses
an unconstrained ASN.1 integer that we wouldn't have run across this
specific problem.
However  I argue that if we've had a transition that could potentially
have issues that's a good argument that we need to have a strategy for
dealing with errors.

There is no discussion in draft-ietf-sidr-arch or
draft-ietf-sidr-res-certs that I was able to find out explaining how
we'll add information to the RPKI if we find we need to do so in a
backward compatible manner.
I believe that this needs to be considered by the WG.

I also recommend that the restrictions in draft-ietf-sidr-res-certs be
relaxed. The restrictions on certificate issuance should remain. The
restrictions on validation should be relaxed to permit unknown
non-critical Extensions. If we decide that for some certificate we do
wish to break backward compatibility we can always introduce a critical

Nothing in section 8 of draft-ietf-sidr-res-certs causes me to believe
that the extensibility model of the RPKI is significantly differnt than
the model already described in RFC 5280.

There's also a consistency problem between RFC 5280 and
draft-ietf-sidr-res-certs. Section 4.6 and 4.7 describe validFrom and
ValidTo elements. Shouldn't these be notBefore and notAfter?