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

Declan Ma <> Sun, 10 July 2016 14:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9808112D0CC for <>; Sun, 10 Jul 2016 07:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g-EyI3KNphIv for <>; Sun, 10 Jul 2016 07:12:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC4C112D0BB for <>; Sun, 10 Jul 2016 07:12:48 -0700 (PDT)
X-TM-DID: 2020b6d4af0409ee41a0a47a5c11a8b8
Content-Type: text/plain; charset="gb2312"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Declan Ma <>
In-Reply-To: <>
Date: Sun, 10 Jul 2016 22:08:25 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Oleg Muravskiy <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: sidr <>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-tree-validation-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Jul 2016 14:12:53 -0000


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.


> 在 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, 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:
>> There's also a htmlized version available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> sidr mailing list
> _______________________________________________
> sidr mailing list