Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-tree-validation-01.txt

From: [email-masked]
Date: Fri, 08 Jul 2016 15:51:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing of the IETF.

        Title           : RPKI Certificate Tree Validation by a Relying Party Tool
        Authors         : Oleg Muravskiy
                          Tim Bruijnzeels
	Filename        : draft-ietf-sidr-rpki-tree-validation-01.txt
	Pages           : 12
	Date            : 2016-07-08

Abstract:
   This document describes the approach to validate the content of the
   RPKI certificate tree, as used by the RIPE NCC RPKI Validator.  This
   approach is independent of a particular object retrieval mechanism.
   This allows it to be used with repositories available over the rsync
   protocol, the RPKI Repository Delta Protocol, and repositories that
   use a mix of both.

   This algorithm does not rely on content of repository directories,
   but uses the Authority Key Identifier (AKI) field of a manifest and a
   certificate revocation list (CRL) objects to discover manifest and
   CRL objects issued by a particular Certificate Authority (CA).  It
   further uses the hashes of manifest entries to discover other objects
   issued by the CA.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-tree-validation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-tree-validation-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Oleg Muravskiy <[email-masked]>
Date: Sat, 9 Jul 2016 01:04:52 +0200

This is an update to the draft-ietf-sidr-rpki-tree-validation.

No major changes, mostly clarifications that address comments from Steve Kent, and additional information as requested at the previous WG session.  Hope this version is more clear and close to final.

Oleg

> On 09 Jul 2016, at 00:51, [email-masked] wrote:
> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Declan Ma <[email-masked]>
Date: Sun, 10 Jul 2016 22:08:25 +0800

Oleg,

I think this version is much better.

Yet I still have a question with Section Security Considerations:

"In contrast, objects whose content hash matches the hash listed in
   the manifest, but that are not located in the publication directory
   listed in their CA certificate, will be used in the validation
   process (although a warning will be issued in that case).”

Given these sorts of objects have been found somehow, in a different repository as described in Section 3.2.2. Manifest entries validation, your RP will take accept them anyway, using them in validation. 

What if this manifest is a stale one when the latest MFT has been deleted maliciously or inadvertently? 

A ROA found in a different repository may has been removed by the administrator and an attacker just replaces this ROA into that ‘different repository’  with poor management. 

There could be many risks here. I wonder why you take this approach.

Di

> 在 2016年7月9日，07:04，Oleg Muravskiy <[email-masked]> 写道：
>

---

From: Oleg Muravskiy <[email-masked]>
Date: Mon, 11 Jul 2016 10:36:31 +0200

Di,

> On 10 Jul 2016, at 16:08, Declan Ma <[email-masked]> wrote:
> 
> Oleg,
> 

Let's look at this case in more detail.

What you describe is that there used to be a valid ROA properly described by a manifest with number X. Then the change happened and in the manifest version X+1 that ROA is not listed anymore, and a new CRL that revokes that ROA is listed. The ROA file is also removed from the repository directory, and new CRL and manifest files replaced their previous versions.

Now, the RP does a new fetch of the repository content, and somehow gets the old version of the manifest, but the new content of directory, so:

- with rsync repository, the rsync stream needs to be tempered with, so that the new manifest is replaced by the old one, but the rest of the stream remains the same;

- with RRDP repository, the content of a snapshot or a delta needs to be tempered with, so that it does not contain a replace for the manifest.

In this situation the validator on the RP side could detect a mismatch, but it needs to decide whom to trust more: the RPKI-signed content of the manifest, or not RPKI-signed (and in case of rsync, not signed at all) content of an RRDP snapshot/delta or an rsync directory.

If we would choose to trust the rsync or RRDP content, then an attacker could easily remove a valid ROA (or certificate) from the stream, which probably is the simplest sort of attack the MITM could implement in case of RPKI. 

So we chose to trust the RPKI-signed content. 

Oleg

---

From: Declan Ma <[email-masked]>
Date: Wed, 13 Jul 2016 00:41:54 +0800

Oleg,

Thanks for your clarifications. You were making sense here. 

Yet I think Section Security Considerations deserves more text of why you take such approach since this section is about your Considerations. Your reasoning is going to help make it in good shape ;-)

Di 

> 在 2016年7月11日，16:36，Oleg Muravskiy <[email-masked]> 写道：
> 
> Di,
>