Subject: Secdir review of draft-ietf-sidr-res-certs

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Mar 2011 12:37:26 -0500

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Mar 2011 10:40:38 -0800

> In other words the profile picks security and minimalism over

This statement is too narrow, and it causes your analysis to come to a 
too narrow conclusion. The profile picks security and minimalism over 
extensibility *of this profile only*. If a flaw is later found that 
requires an extension, that extension will be written up in a 
standards-track document that will obsolete this profile. An 
implementation that conforms to that new profile will use the extension. 
Thus, errors can be corrected with new profiles, and the RPKI will have 
multiple profiles running on it, just as the Internet has multiple 
versions of some protocols running on it.

--Paul Hoffman

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Mar 2011 14:07:31 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> On 3/10/11 9:37 AM, Sam Hartman wrote:
    >> 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.

    Paul> This statement is too narrow, and it causes your analysis to
    Paul> come to a too narrow conclusion. The profile picks security
    Paul> and minimalism over extensibility *of this profile only*. If a
    Paul> flaw is later found that requires an extension, that extension
    Paul> will be written up in a standards-track document that will
    Paul> obsolete this profile. An implementation that conforms to that
    Paul> new profile will use the extension. Thus, errors can be
    Paul> corrected with new profiles, and the RPKI will have multiple
    Paul> profiles running on it, just as the Internet has multiple
    Paul> versions of some protocols running on it.

Paul, that's a great argument for why it's OK to prohibit issuing
certificates with new extensions in this profile.
We absolutely can change CA behavior with a new profile.

However, I don't think your argument makes sense for RP behavior.
Under this profile, if an RP is presented with a certificate issued
under a new RPKI profile, it will reject that certificate.

So, it sounds a lot like you'd need to upgrade all the RPs that might
need to rely on a particular resource certificate before  you could
issue that certificate under a new profile.
Given that resource certificates can be used by a lot of RPs--for
example anyone who needs to verify origins of a route presumably--that's
a long wait.
I think that's unjustified.

One of us is clearly missing something. I would be happy if it's me.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Mar 2011 11:31:42 -0800

On 3/10/11 11:07 AM, Sam Hartman wrote:
>>>>>> "Paul" == Paul Hoffman<[email-masked]>  writes:
>

I don't think either of us is missing something, we just disagree about 
what needs to happen if a fix that changes the semantics of the certs 
needs to be made to the system as a whole. For changes that don't change 
the semantics, you change an existing extension or other part of the 
certificate; for changes that need to change the system's semantics, you 
change the certificates in a way that relying parties that don't 
understand the change won't accept the certificate.

Maybe you and I are envisioning different choices being made about those 
changes. I trust the IETF not to make a change that will cause a lot of 
relying parties to fail unless the IETF really thinks that is necessary; 
you may have less faith than I do. (You were on the IESG, so you get to 
be in the sausage-making more than I have...)

---

From: Rob Austein <[email-masked]>
Date: Thu, 10 Mar 2011 14:56:04 -0500

Speaking as someone who has implemented relying party tools for this,
I support the current restrictive choices in the profile, for a very
simple reason: I can't validate what I don't understand.  The current
profile is written to restrict what's allowed today to things we
understand today.  As Paul says, if we understand something new
tomorrow, we'll have to update both profile and code.

"La perfection soit atteinte non quand il n'y a plus rien à ajouter,
mais quand il n'y a plus rien à retrancher."

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Mar 2011 15:53:44 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> I don't think either of us is missing something, we just
    Paul> disagree about what needs to happen if a fix that changes the
    Paul> semantics of the certs needs to be made to the system as a
    Paul> whole. For changes that don't change the semantics, you change
    Paul> an existing extension or other part of the certificate; for
    Paul> changes that need to change the system's semantics, you change
    Paul> the certificates in a way that relying parties that don't
    Paul> understand the change won't accept the certificate.

    Paul> Maybe you and I are envisioning different choices being made
    Paul> about those changes. I trust the IETF not to make a change
    Paul> that will cause a lot of relying parties to fail unless the
    Paul> IETF really thinks that is necessary; you may have less faith
    Paul> than I do. (You were on the IESG, so you get to be in the
    Paul> sausage-making more than I have...)

I do trust the IETF, which is why I think the current document is very
broken.  I want to give the IETF the *future* opportunity to balance
breaking RPs against confusing behavior.

I hate to get into a specific example, because it's very easy to attack
the example without the general point. However in the interests of
trying to explore our difference, I'd like to come up with a specific
example. I may drop the discussion if I feel that we're focusing on the
example rather than the general point.

So let's pretend that we'd been much more efficient about SIDR and that
the RPKI was done prior to 32-bit ASes being a significant issue.  Let's
pretend that RFC 3779 managed to specify the AS constraint in such a way
that 32-bit ASes were excluded. Perhaps there is an ASN.1 constraint on
the size of the AS that happens to be rigorously enforced by widely
deployed RPs.
Regardless of how it happened, assume that we cannot encode 32-bit ASes
in the existing extension.

In the current model, we have to come up with a new extension.
I think this means you need a new independent CA hierarchy for the
32-bit AS certificates. New RPs can use that hierarchy for 32-bit
ASes, all RPs use the old hierarchy for the 16-bit AS certs and to
the extent they are combined IP certs.
In theory we could some day combine these hierarchies when all the RPs
support 32-bit ASes. In practice we probably wouldn't because someone
out there would implement an RP that broke when the hierarchies were
combined and even though it would simplify things the risk of breakage
would not justify combining the hierarchies.

I'm not sure if this model works: I'd need to analyze whether you can
have multiple signatures on an RPKI object, whether you need to claim
both an AS and an IP address in signing a route, etc etc.  If we're
going to go forward with the current model we need at least convince
ourselves that even if we did have to duplicate the RPKI to deploy some
feature we could do so and not also duplicate the instances of the
protocols signing RPKI objects.

However, if we had a relaxed model, we'd give the IETF another option.
The IETF could also provide a new version of the AS extension for 32-bit
ASes.  There are huge tradeoffs here.  Only new RPs will validate the
32-bit ASes. So you can get into a situation where an RP who is unaware
of 32-bit ASes accepts a certificate that a newer RP would
reject. However, the 16-bit ASes in that certificate would validate. The
IP addresses in that certificate would validate.  An appropriately
authorized trust anchor would need to create a certificate with a valid
certification path that passed all the checks in the old profile.  Such
a certificate could only be used by an old-profile RP to validate
objects permitted under the old profile. An RP that understood 32-bit
ASes would be required to understand the 32-bit AS validation.

I don't know what the right choice would be in this situation.
However in similar situations I'd prefer to make that choice in the
future when the IETF is in a position to evaluate the tradeoffs rather
than forcing our hand now.

Similarly you could imagine a desire to add information to a certificate
for auditing, debugging or the like, where validation rules were not
changed. Again, I'd prefer to allow the IETF to decide whether breaking
RPs should be required to make such changes in the future rather than
now.  

Again, because of extension criticality, we always have the option to
force RPs to reject new things they don't understand. The question is
whether we want options beyond that.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2011 19:21:22 -0500

Sam,

The cert profile is intentionally very restrictive, as you noted.  A 
primary rationale is that we are asking folks who manage address (and 
AS#) allocation to act as CAs , and we want to limit their liability. 
One way to do this is to restrict the fields and extensions in 
resource certs to make then not very useful for other applications. 
we also wanted to make it as easy as possible for relying parties to 
process resource certs. X.509 has a lot of potentially complex 
"features" and RFC 5280 did not kill off as many as some of would 
have liked :-). So, profiling certs (and CRLs) for the RPKI makes 
sense. Allowing unknown, non-critical extensions would undermine this 
stragey.  Much as I liked Jon Postel, and worked with him on the IAB 
for a decade, his oft cited dictum is bad design advice in the 
security arena.

I also note that we want to impose these constraints on both CAs and 
RPs, because we have lots of examples of CAs issuing "bad" certs, 
accidentally. se want to use RP strictness to help "motivate" CAs to 
do the right thing :-).

I must admit that I found it a bit amusing that you chose to 
illustrate the potential for a change that would motivate being less 
stringent by citing RFC 3779, which you noted didn't have the problem 
in question :-). (Also note that integers usually are not very much 
constrained in ASN.1 in general, so the observation you made there 
seems a bit odd to me.)

Nonetheless, I get your point. My response is that IF we discover a 
need to change the profile, we could do so, e.g., by changing the 
cert policy (since the policy is specified in the CP, which 
references this version of the cert profile. Any change of this sort 
would have to be phased in over a long time scale.  I suggest you 
look at the algorithm agility I-D for RPKI to see the sort of 
planning envisioned for that sort of change.

I do agree that there is a typo in the doc, re the validity interval. 
Sean noted that after the doc was released, and we agreed that it can 
be fixed after last call.

Steve

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 10 Mar 2011 22:36:11 -0500

On Thu, 2011-03-10 at 11:31 -0800, Paul Hoffman wrote:
>  for changes that need to change the system's semantics, you 

Sure.  The way to do that is to issue a certificate with a critical
extension.  An RP encountering a certificate with a critical extension
it doesn't understand will not accept the certificate.

What the profile does as written is require RP's to treat all extensions
as critical, even if they are not so marked.  That reduces flexibility
without gaining anything in return.  In particular, we don't gain the
ability to make a change that will prevent certificates from being
accpted by RPs that don't understand them, because we already had that.

Steve noted a desire to limit the liability of entities acting as CAs in
the RPKI.  I agree that goal is desirable, and restrictions on what
certificates issued by those CAs can contain help to do that (provided
the CAs actually comply).  However, requiring compliant RPs to treat all
extensions as critical does _not_ help, because an RP which incorrectly
accepts an over-broad RPKI certificate for some other purpose is
probably not an implementation of this profile and thus not bound by the
restriction.

--Jeff

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Mar 2011 05:58:42 +0100 (MET)

Stephen Kent wrote:
> 
> n to act as CAs , and we want to limit their liability. 

A CA should never sign extensions that it doesn't understand.
Why has the RP to be bothered with this?

A request "everything must be considered critical, even if not marked
as such" implies that every conceivable extension can only be a constraint.

With its original meaning, the "ciriticality" flag could be used to sort
extensions into "constraints" (critical) and "capabilities" (non-critical).

The problem with newly inventend constraints is that they require flag days.
capabilities do not suffer from this, and allow for a smoother migration.

> accidentally. se want to use RP strictness to help "motivate" CAs to 

I don't think that this idea will work.
The consumers of the technology will want things to interoperate,
not to fail.  And implementations will provide the necessary workarouds.

Besides, such an idea is in conflict with rfc-2119 section 6

6. Guidance in the use of these Imperatives

   ... they must not be used to try to impose a particular method
   on implementors where the method is not required for interoperability.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2011 11:41:19 -0400

Jeff
>probably not an implementation of this profile and thus not bound by the

My comments also noted that part of the strategy to limit the utility of
resource certs in other contexts is to restrict their content. In principle,
establishing constraints on what RPKI C As issue would do this, but 
experience suggests otherwise :-).  Thus, in order to provide 
immediate feedback to a CA that the certs it is issuing are 
non-compliant, we would like to have RPs reject the certs (when used 
in the intended context). Thus having RPs be very strict in what they 
accept is important as well.

Steve

P.S.

Sam noted that there are potentially lots of RPs.  In principle, 
there are just as many CAs, since every ISP is a CA as well as an RP. 
In reality we anticipate that many small ISPs will take advantage of 
managed CA services (the RIRs are already offering such services), so 
there should be many fewer distinct CAs vs. RPs.  Balancing that is 
the possibility that a number of ISPs, ones that rely on default 
routes, will also not be RPs. So, it's not clear whether we have more 
(distinct) CA or RPs.  I am hopeful that the RIRs will do a good job 
of generating compliant certs in their primary and managed service CA 
roles.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2011 11:41:19 -0400

>Why has the RP to be bothered with this?

this is not about signing certs with extensions submitted by a 
Subject and which the CA does not understand.

>as such" implies that every conceivable extension can only be a constraint.

I would prefer to say that the vast majority of extensions are 
excluded from this profile, to make it easier for RP software to 
process resource certs. The critical marking is not equivalent to 
what we have stated in this doc, although there are similarities. For 
example, there are a lot of standard extensions that 5280 requires RP 
software to recognize that are explicitly forbidden in the RPKI 
context.

>extensions into "constraints" (critical) and "capabilities" (non-critical).

Note that not all extensions can be marked critical, so that using 
the critical flag would not be a solution in all cases anyway.

>capabilities do not suffer from this, and allow for a smoother migration.

This doc is a profile of 5280 and thus the imposition of constraints 
is to be expected. I do not know what you mean by the phrase "... 
capabilities do not suffer from this ..."

>not to fail.  And implementations will provide the necessary workarouds.

Interoperability is NOT enhanced by allowing certs with extensions 
that are extraneous to the focus of this architecture, and to the CP 
for this PKI. I suggest you read the architecture doc and the CP, 
both of which are available at the SIDR page to get a better sense of 
the context targeted by this profile.

>    on implementors where the method is not required for interoperability.

I disagree with our reading of this text, relative to this context.

Steve