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

[Sam Hartman <[e-mail]>]

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
certificates.

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
subjectAlternativeName.
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
accept.
In other words the profile picks security and minimalism over
extensibility.

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
manner.

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
there.)
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
Extension.

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?

Thanks,

--Sam