Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: text/plain; charset=utf-8
From: Oleg Muravskiy <oleg@ripe.net>
In-Reply-To: <1CE8D4C6-D1DF-4368-9770-392153076D91@zdns.cn>
Date: Mon, 11 Jul 2016 10:36:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1C22A63-066E-4232-B10B-D8827B9B4715@ripe.net>
References: <20160708225123.32075.21604.idtracker@ietfa.amsl.com>
 <100F7109-D601-478A-959D-7260AC21A31A@ripe.net>
 <1CE8D4C6-D1DF-4368-9770-392153076D91@zdns.cn>
To: Declan Ma <madi@zdns.cn>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/8-E5ZtpIAXx1IjPldyFjsE7b7OA>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-tree-validation-01.txt
Precedence: list

Di,

> On 10 Jul 2016, at 16:08, Declan Ma <madi@zdns.cn> wrote:
>=20
> Oleg,
>=20
> I think this version is much better.
>=20
> Yet I still have a question with Section Security Considerations:
>=20
> "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).=E2=80=9D
>=20
> 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.=20
>=20
> What if this manifest is a stale one when the latest MFT has been =
deleted maliciously or inadvertently?=20
>=20
> A ROA found in a different repository may has been removed by the =
administrator and an attacker just replaces this ROA into that =
=E2=80=98different repository=E2=80=99  with poor management.=20
>=20
> There could be many risks here. I wonder why you take this approach.
>=20
> Di

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.=20

So we chose to trust the RPKI-signed content.=20


Oleg

>=20
>=20
>=20
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=889=E6=97=A5=EF=BC=8C07:04=EF=BC=8COleg =
Muravskiy <oleg@ripe.net> =E5=86=99=E9=81=93=EF=BC=9A
>>=20
>> This is an update to the draft-ietf-sidr-rpki-tree-validation.
>>=20
>> 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.
>>=20
>>=20
>> Oleg
>>=20
>>=20
>>> On 09 Jul 2016, at 00:51, internet-drafts@ietf.org wrote:
>>>=20
>>>=20
>>> 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.
>>>=20
>>>      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
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> =
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-tree-validation/
>>>=20
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-01
>>>=20
>>> A diff from the previous version is available at:
>>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-tree-validation-0=
1
>>>=20
>>>=20
>>> 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.
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>>=20
>>=20
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>=20
>=20