Subject: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 9 Mar 2017 18:44:58 +0000

Dear authors:

I just finished reading this document.  My review is predicated on the assumption that the intent of the WG is to define an additional validation process, and not amend/change/update/deprecate the existing one…yet, which is why there are not only process changes specified, but also new OIDs.

As written, with Updates and text “to be used in place of” existing specifications, the document achieves the deprecation of the current (old) mechanism: simply because procedurally you are replacing the existing/old text with the new one…and the old one would then not be anymore.  The result then is not coherent with the assumption above, and we will need to rewrite (at least from an intent point of view) the document before progressing.

I think that the easiest way forward would be for this document to say something like: “a new validation mechanism is specified, which uses these new OIDs – the specifications defined in RFCA, RFCB, etc.. apply, except for the following exceptions/changes.”  You should then be able to use most of the substantive text already written.

Please see below for specific comments – including more on why this document should not Update the existing RFCs.

Thanks!

Alvaro.

Major:

M1. Section 4.2.1. (Changes to RFC6484).  This document requests an assignment of a new OID (id-cp-ipAddr-asNumber-v2); both the reference and the policy to be followed are contained here, and not in RFC6484.  IOW, this document shouldn’t Update RFC6484.  Instead, it should request the new OID and simply reference RFC6484 when pointing back to id-cp-ipAddr-asNumber.

M2. Section 4.2.2. (Changes to RFC3779).  Same comment: this document requests the assignment of new OIDs….  Note that if the changes in Section 4.2.2.1. (OID for id-pe-ipAddrBlocks-v2) and Section 4.2.2.3. (OID for id-pe-autonomousSysIds-v2) were to be used in place of the text in RFC3779, then id-pe-ipAddrBlocks and id-pe-autonomousSysIds would end up being deprecated.

M2.1. [minor] The syntax for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 (4.2.2.2 and 4.2.2.4) use the “v1” names.

M2.2. For Sections 4.2.2.5 and 4.2.2.6, I think that what you want to say is (something like): “when the OIDs defined in this document are used, the procedures in RFC3779 are followed, except for the certificate path validation (section 2.3), which is specified in Section 4.2.4.4 of this document, and…”  Again, if the text was to replace what is currently in RFC3779, then those procedures would be deprecated.

M2.3. Same comment for Section 4.2.2.7: amending the specification in RFC3779 results in loosing what is defined there.

M3. Section 4.2.4. (Changes to RFC6487).  Same comments as above: replacing the text (which is what an Update does), would result in the mechanism specified in RFC6487 to be the same as what is specified in this document…which means that the option in the first paragraph (“…MUST issue certificates either as specified in [RFC6487] or with all the amendments specified in the following sections.) would result in the same thing.  As with Section 4.2.2 (above), I think you really should specify what the exceptions are for the extensions defined in this document (and not Update RFC6487).

M4. Section 4.2.4.4. (Amended Resource Certificate Path Validation).

M4.1. [Comment about RFC6487] This document correctly mentions the NotBefore/NotAfter values (which should really be notBefore/notAfter), instead of From/To (in RFC6487).  It seems to me that this is an error in the original text.  Can you please file an Errata against RFC6487?

M4.2. s/Certificate x contains all the extensions that MUST be present/Certificate x contains all the required extensions    The “MUST” is not normative in this context.

M4.3. [minor] s/MUST be satisfy the constraints/MUST satisfy the constraints

M4.4. “If IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.”  What is replaced, the IP Address Delegation extension or the VRS-IP?  If the extension, what does it mean to replace the extension in the certificate?   Note that the text about the AS Identifier Delegation extension is as confusing.

M4.5. “…these values MAY be stored along with the certificate, to facilitate incremental validation…”  This document (and RFC6487) don’t say anything about where to store anything – I don’t think we need that normative “MAY”.   s/MAY/may

M4.6. This text is not needed: “If certificate x uses the original version of [RFC6487], then certificate x MUST be rejected.”

M5. Section 4.2.5. (Changes to RFC6482).  Same comment about not needing an Update/replacing the text/…

M6. Section 5. (Deployment Considerations).  The timeline in Table 1 shouldn’t appear in this specification.  Migration is an operational issue that the community should coordinate separately (and not by specifying a normative timeline in an RFC).  What should be included here are any other migration considerations that should be observed when making the transition – if there’s anything beyond what you already wrote.

M7. Section 6. (Security Considerations). Please point to the security considerations in RFC3779, RFC6482, RFC6484 and RFC6487 as applying here too.  It might be beneficial to include a short discussion of why not immediately rejecting the over-claiming certificates is not a security issue

M8. IANA Considerations.   TBD4/TBD5 are not for IPAddrAndASCertExtn-*, but for the new id-mod-ip-addr-and-as-ident-*.

M9. References
- Please add a reference to RFC2119 and the corresponding boilerplate.
- I don’t think that the reference to RFC6268 needs to me Normative.
- We don’t need references to RFC3849, RFC5398 or RFC5737.
- RFC3280 was Obsoleted by RFC5280

Minor:

P1.  The example in Section 3 is meant to be a continuation from the example in Section 2 (“Certificate 2 from the previous example was re-issued by TA to CA1 and the prefix 198.51.100.0/24 was removed.  However, CA1 failed to re-issue a new Certificate 3 to CA2.”); but Certificate 3 is not the same as the one shown in Section 2.  I think the example still gets the over-claiming point across, but it is “wrong” in that both Certificate 2 and Certificate 3 (not just Certificate 2) would have to change for the problem to happen.

P2, Also in the example in Section 3.  It might be beneficial for the reader if the EE certificate was also marked as invalid; the text says so, but the list of certificates doesn’t.

P3. In several places “[this document]” is used – if the intent is to refer to a specific Section, please indicate which.  If not, then you should get rid of the brackets ([]).

P4. In 4.3: “ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate, as required by RFC 6482.”  The VRS is introduced in this document, not RFC6482.

Nits:

N1. “This document proposes…” and “The changes proposed here…”.  We’re past the proposal phase: “This document specifies…”

N2. s/ maintaining Verified Resource Set/ maintaining a Verified Resource Set

N3. s/ the loss of on IP address prefix/ the loss of one IP address prefix

N4. s/ the 1988 ASN.1 modules for which we provided an update in Section 4.2.2.7 remain the normative version/ the 1988 ASN.1 modules in Section 4.2.2.7 remain the normative version

N5. s/ Furthermore we wish to note that operators MAY issue separate BGPsec Router Certificates for different ASNs/ Operators MAY issue separate BGPsec Router Certificates for different ASNs

---

From: Rob Austein <[email-masked]>
Date: Sat, 11 Mar 2017 17:25:27 -0500

At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote:
> 
> I just finished reading this document.  My review is predicated on
> the assumption that the intent of the WG is to define an additional
> validation process, and not amend/change/update/deprecate the
> existing one?yet, which is why there are not only process changes
> specified, but also new OIDs.

Alvaro,

I will let the WG chairs and authors speak to intent regarding the
existing validation process.

Speaking as an implementer, I requested, nay, demanded the new OIDs,
for a very simple technical reason: from an implementation standpoint,
the new validation rule is very different from the old one.  More
precisely, it is very close to the same set of checks as the old rule,
but in a very different place in the code.  Given the overall
structure of X.509v3's critical extension mechanism, new OIDs were by
far the simplest means of signalling which rule an RP should use.

So the decision to use new OIDs is orthogonal to the deprecation
discussion: we need the new OIDs in any case for technical reasons.

---

From: Chris Morrow <[email-masked]>
Date: Sun, 12 Mar 2017 14:28:51 -0400

At Sat, 11 Mar 2017 17:25:27 -0500,
> existing validation process.

I think the intent of the WG is still to add the new validation
process, then deprecate the original once all users are on code which
supports the 'new' way.

-chris

---

From: Declan Ma <[email-masked]>
Date: Mon, 13 Mar 2017 14:16:59 +0800

Speaking as the representative of RPSTIR team,

We are working on RPSTIR update in order to make it use the new algorithm to do INR validation. 

Before RP performs the new validation process, it needs to get the INRs from certificates.  And we found a bug of OPENSSL library when using OPENSSL to get resource sets from certificates, so we wrote our own code to do so.  

It seems to me that the only concern on OID is about using OPENSSL to get resource sets for further validation process. If the WG has decided to deprecate the original by using the Validation Reconsidered, why bother to bring a new OID ?

Declan(Di) Ma

ZDNS 

> 在 2017年3月13日，02:28，Chris Morrow <[email-masked]> 写道：
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 13 Mar 2017 10:55:56 +0100

Hi,

So, to me it seems that having new OIDs makes perfect sense as long as there is a choice of two validation algorithms. Then having an explicit flag set by CAs tells RPs decide which way to go. Because of this I also do not see an immediate need to have a time line for all CAs to use the new protocol for all its products. It's all explicit.

Now, if the ambition is to have reconsidered as the only algorithm for doing RPKI validation, then I think that the RPKI Certificate Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text on path validation as well, but I think could can recognise that a different algorithm should apply in the context of *RPKI* validation.

If I understand Rob's concerns though he feels that this will cause issues, and that therefore the RFC3779 OID cannot be used. Rob, is this correct? Why can't RP/OpenSSL code just make the switch based on the CA certificate profile?

Cheers
Tim

> On 13 Mar 2017, at 07:16, Declan Ma <[email-masked]> wrote:
>

---

From: Rob Austein <[email-masked]>
Date: Mon, 13 Mar 2017 08:47:11 -0400

At Mon, 13 Mar 2017 14:16:59 +0800, Declan Ma wrote:
...
> It seems to me that the only concern on OID is about using OPENSSL
> to get resource sets for further validation process. If the WG has
> decided to deprecate the original by using the Validation
> Reconsidered, why bother to bring a new OID ? 

Because library code which thinks it understands RFC 3779 has been
shipping for a decade now, and the WG has no magic wand which can make
that library code go away.  It is very poor form to retroactively
change the semantics of something that has already shipped, at least
when there is an easy way to avoid the problem, as there is here.

---

From: Rob Austein <[email-masked]>
Date: Mon, 13 Mar 2017 09:11:55 -0400

At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote:
> 
> So, to me it seems that having new OIDs makes perfect sense as long
> as there is a choice of two validation algorithms. Then having an
> explicit flag set by CAs tells RPs decide which way to go. Because
> of this I also do not see an immediate need to have a time line for
> all CAs to use the new protocol for all its products. It's all
> explicit.
> 
> Now, if the ambition is to have reconsidered as the only algorithm
> for doing RPKI validation, then I think that the RPKI Certificate
> Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to
> section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text
> on path validation as well, but I think could can recognise that a
> different algorithm should apply in the context of *RPKI*
> validation.
> 
> If I understand Rob's concerns though he feels that this will cause
> issues, and that therefore the RFC3779 OID cannot be used. Rob, is
> this correct? Why can't RP/OpenSSL code just make the switch based
> on the CA certificate profile?

The problem is that there are one or two things out there besides RPKI
which use X.509, and it would be nice to avoid breaking them.

The OIDs which MUST be changed are the ones labeling the extensions
themselves.  The semantics of X.509v3 critical extensions says,
basically, "If you don't understand the meaning of this extension, you
MUST consider this certificate invalid".  Changing the meaning of the
extensions while retaining the existing OIDs would break this: there
is code out there which thinks it does understand the RFC 3779
extensions, but which would now be incorrect, because the RFC 3779
OIDs would now be used to label things that are not RFC 3779
extensions.

Granted, the probability that some random X.509 CA is going to include
RFC 3779 extensions in certificates for any purpose other than RPKI is
fairly low, but it would be nice to avoid creating a situation in
which users of such certificates got inconsistent results depending on
which version of a stock library they happened to use.  If this were
OpenSSL doing something stupid I wouldn't care so much, but this was
OpenSSL implementing an IETF proposed standard to the best of the
author's ability, and you're talking about retroactively breaking that
for gratuitous reasons.  This is irresponsible.  Don't do it.

I don't understand why we're wasting time debating this (again).  OIDs
are cheap, and (I thought) this was a done deal.  Can we please just
admit that we're talking about new extensions with new semantics which
borrow syntax from the existing extensions, label them accordingly,
and move on?

---

From: Chris Morrow <[email-masked]>
Date: Mon, 13 Mar 2017 10:15:58 -0400

At Mon, 13 Mar 2017 08:47:11 -0400,
> when there is an easy way to avoid the problem, as there is here.

new oid's seemed reasonable to me... as a chemical engineer playing
security engineer on network things.

-chris

---

From: Chris Morrow <[email-masked]>
Date: Mon, 13 Mar 2017 10:21:06 -0400

At Mon, 13 Mar 2017 10:55:56 +0100,
Tim Bruijnzeels <[email-masked]> wrote:
> 
> Hi,
> 
> So, to me it seems that having new OIDs makes perfect sense as long as
> there is a choice of two validation algorithms. Then having an
> explicit flag set by CAs tells RPs decide which way to go. Because of
> this I also do not see an immediate need to have a time line for all
> CAs to use the new protocol for all its products. It's all explicit.

I was thinking that today code for CA/RP doesn't understand (mostly)
the 'new' way. Tomorrow 'some' of the CA/RP world will shift to being
able to do both ways.

So, until all of the CA/RP software is updated and deployed, CAs can't
make new OID/validation content and expect them to be respected. I
expect a transition to the new validation algorithm (for even a single
CA) will have to wait until this point in time. Once there are new and
old validation algorithm data available a CA probably should flush the
'old' and publish the 'new'. I think Tim's correct that an RP can see:
  "Oh, new OID here, run new algorithm!"

and be perfectly fine... but, having 2 versions of the validation
algorithm and seeing published data for both OID sets for a single
prefix/publication bundle will be very problematic. There's no
proscribed 'prefer new over old' action here, so a CA must only
publish one version of their data.

-chris

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 13 Mar 2017 15:25:13 +0100

Hi Rob, all,

> On 13 Mar 2017, at 14:11, Rob Austein <[email-masked]> wrote:
> 

I understand that. I meant to say that the switch should be based on the RPKI CA certificate policy qualifier. That is specific to RPKI so, other applications would not break.

Non-RPKI use of RFC3779, would not have this same OID, and therefore would still have the path validation from section 2.3 in RFC3779.

> borrow syntax from the existing extensions, label them accordingly,

The reason why I keep talking about this, is because other people indicated that it could be desirable that validation reconsidered is not a choice (that would need flagging, so OIDs are appropriate) - but should become the default.

In that case it's much simpler to have a switch on the unique RPKI CP OID from section 1.2 of RFC6484. 

The proposed OIDs itself are cheap, and the code changes are simple. The difficulty is that we need a deployment plan:

1= RPs MUST support new OIDs, before
2= CAs MAY use new OIDs

and an open question still is whether there needs to be a later
3= CAs MUST use new OIDs and RPs MUST reject old OIDs

Step 2 has operational impact if operators did not upgrade their RP software. Step 3 has operational impact in case a CA cannot re-issue certain objects.

If we need to end up in a place where 'validation reconsidered' is the default, then these operational impacts can be minimised. It would boil down to deciding a date X by which RPs MUST use reconsidered when they encounter the RPKI CP OID, and a date Y (before X) that these should be available. Operators that don't upgrade before date X could find that they consider certain objects invalid, that would be (partially) valid.

In any case, I know that you know more about how the openssl code works. So if there is a reason why the switch cannot work on the RPKI CP OID without affecting non-RPKI use, or if there is a strong reason for having both algorithms alongside each other, than I am (still) open to the OIDs that I painstakingly added to the document.

Tim

---

From: Rob Austein <[email-masked]>
Date: Mon, 13 Mar 2017 11:16:57 -0400

At Mon, 13 Mar 2017 15:25:13 +0100, Tim Bruijnzeels wrote:
> 
> I understand that. I meant to say that the switch should be based on
> the RPKI CA certificate policy qualifier. That is specific to RPKI
> so, other applications would not break.

The problem is that you're talking about applications, while I'm
talking about libraries.

> Non-RPKI use of RFC3779, would not have this same OID, and therefore
> would still have the path validation from section 2.3 in RFC3779.

You are making assumptions about how the library code works.  As it
happens, those assumptions are incorrect for the OpenSSL case.

> The reason why I keep talking about this, is because other people
> indicated that it could be desirable that validation reconsidered is
> not a choice (that would need flagging, so OIDs are appropriate) -
> but should become the default.
> 

I disagree.

> The proposed OIDs itself are cheap, and the code changes are
> simple. The difficulty is that we need a deployment plan:
> 
> Step 2 has operational impact if operators did not upgrade their RP
> software. Step 3 has operational impact in case a CA cannot re-issue
> certain objects.

Old-policy-OID requires old-extension-OIDs.  New-policy-OID requires
new-extension-OIDs.  Simple, unambiguous, no magic required.

> If we need to end up in a place where 'validation reconsidered' is
> the default, then these operational impacts can be minimised.

Hiding the change does not solve the problem, it just makes it harder
to debug when it breaks.

> In any case, I know that you know more about how the openssl code
> works. So if there is a reason why the switch cannot work on the
> RPKI CP OID without affecting non-RPKI use, or if there is a strong
> reason for having both algorithms alongside each other, than I am
> (still) open to the OIDs that I painstakingly added to the
> document.

That's what I've been trying to tell you.

At least in OpenSSL's case, certificate extensions are processed down
in the guts of the library.  Certificates with critical extensions
which do not pass validation are rejected by the library, regardless
of any policy setting.  Policy OID constraints require cooperation by
the application.

So while your scheme sort of works for RPKI-aware applications which
enforce an RPKI policy OID, it does not work for non-RPKI applications
which encounter RFC 3997 extensions: you will get the same certificate
looking valid to one validation engine and invalid to another, because
the same OIDs trigger different processing in the two engines.

Don't go there.  Please, don't go there.  This is dangerous.

Please just keep the new separate extension OIDs and stop trying to
pretend that we can sweep the flag days for an incompatible change
under the rug.  We can't.  Accept that and move on.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 13 Mar 2017 12:44:45 -0300

Rob,

> happens, those assumptions are incorrect for the OpenSSL case.

can you expand on this ? I think if you help us on this front a lot of 
the concerns and misunderstandings will be sorted out.

Best regards,

-Carlos

---

From: Declan Ma <[email-masked]>
Date: Tue, 14 Mar 2017 14:23:01 +0800

+1

As far as we programmed to support Validation Reconsidered by using OPENSSL , a bug was found.

For instance, if one calls v3_addr_get_range() in OPENSSEL library to get INR 1::/16 from a RC, one will get a right MAX but a wrong MIN NULL, which should have been 1:: .

Di

> 在 2017年3月13日，23:44，Carlos M. Martinez <[email-masked]> 写道：
> 
> Rob,
> 
> can you expand on this ? I think if you help us on this front a lot of the concerns and misunderstandings will be sorted out.
> 
> Best regards,
> 
> -Carlos
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 15 Mar 2017 10:24:33 +0100

Hi Chris,

> On 13 Mar 2017, at 15:21, Chris Morrow <[email-masked]> wrote:
> 
> but, having 2 versions of the validation

Why is this a problem, really?

The OIDs are set on a per certificate basis by the issuing CA. FWIW, in our hosted set up we *will* be able to pro-actively re-issue everything using the new OIDs without user interaction, but there are cases in hosted CA deployments where a hosted CA can automatically re-issue manifests, but ROAs can only be re-issued by explicit user request, one by one.

So we may see hosted CAs with products like this:

1 CRL (validation algorithm does not apply)
1 MFT (new validation, although it won't matter because inherit is used)
1 ROA with new validation (which has been re-issued by the user)
1 ROA with old validation (which has NOT yet been re-issued)

This might seem confusing, but since the OIDs make it very explicit which algorithm the CA intended to use, I really do not see any ambiguity here.

My main concern is that we need to be quite confident that new RP code that understands the new OIDs has been available and is deployed. Because old RPs will reject EVERYTHING once CAs start using the new OIDs.

That is why I would have preferred to not need new OIDs, and just agree on a day that the new algorithm should be preferred. Rob seems adamant that the RFC3779 extension library code does not have access to the context of the full certificate with the RPKI CP OID - so there is no way to have something like:

if (FULL certificate has RPKI CP OID && Date is after 'switch' day) {
  do NEW on RFC3779 extension
} else {
  do OLD on RFC3779 extension
}

The impact of RP software not using the new library on 'switch' day is fairly limited. They would not reject the full repository, but only reject the exceptional cases where certificates ARE over-claiming. And of course the date check can be removed in releases of the library after 'switch' day..

It seems to me that this is a design issue with OpenSSL itself, but be that as it may - it may be unsurmountable. Rob knows this code much better than I do.

Still the consequence of all this is is that we will have to have a mix, and that despite our best efforts to warn everyone to upgrade their RP software I expect that we WILL see a number of operators that suddenly find that their old RP software has reject our full repository when start using the new OIDs.

If it can't be avoided than so be it, but I believe this perspective should be considered as well.

Cheers

Tim