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 写道：
>
> Di,
>
>> On 10 Jul 2016, at 16:08, Declan Ma wrote:
>>
>> 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
>
> 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
>
>>
>>
>>
>>> 在 2016年7月9日，07:04，Oleg Muravskiy 写道：
>>>
>>> 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, internet-dra...@ietf.org wrote:
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.ie
