Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track

Geoff Huston <gih@apnic.net> Mon, 18 July 2011 01:29 UTC

Return-Path: <gih@apnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C36E21F889D for <sidr@ietfa.amsl.com>; Sun, 17 Jul 2011 18:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.895
X-Spam-Level:
X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcfLgkRpxx9U for <sidr@ietfa.amsl.com>; Sun, 17 Jul 2011 18:29:36 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29C21F8741 for <sidr@ietf.org>; Sun, 17 Jul 2011 18:29:35 -0700 (PDT)
Received: from joan-vista.canberra.aarnet.edu.au (joan-vista.canberra.aarnet.edu.au [202.158.221.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id BA35DB68D8; Mon, 18 Jul 2011 11:29:33 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <CA49B09E.17E05%terry.manderson@icann.org>
Date: Mon, 18 Jul 2011 11:29:27 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5E0EB84-C1FC-46E9-9CAD-1AC1632F701A@apnic.net>
References: <CA49B09E.17E05%terry.manderson@icann.org>
To: Terry Manderson <terry.manderson@icann.org>
X-Mailer: Apple Mail (2.1084)
Cc: Rob Austein <sra@isc.org>, "draft-ietf-sidr-repos-struct@tools.ietf.org" <draft-ietf-sidr-repos-struct@tools.ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2011 01:29:36 -0000

On 18/07/2011, at 9:42 AM, Terry Manderson wrote:

> 
> 
> 
> On 18/07/11 12:53 AM, "Rob Austein" <sra@isc.org> wrote:
> 
>> This draft defines the mappings from filename extension (.cer, .roa,
>> .crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc).
>> 
>> Without this mapping, relying party tools have no way of knowing what
>> they're looking at in most cases, and would have to attempt to decode
>> every object in various ways to see which (if any) worked.  This would
>> be tedious, error prone, and generally a bad idea.
>> 
> 
> This actually makes me wonder why the manifest (
> draft-ietf-sidr-rpki-manifests) in:
> 
> FileAndHash ::=     SEQUENCE {
>      file            IA5String,
>      hash            BIT STRING
>      }
> 
> Doesn't have a RPKIObjectIdentifier that tells the relying party what the
> object it has just retrieved is in terms of ROA/CERT/etc, as a signed
> attestation.


I don't have an answer - it's a good question.

> 
> (and then an appropriate IANA registry for RPKIObjectIdentifier could then
> be created and populated as a standards track)
> 
> If repos-struct was standards track and the naming scheme was the prime
> mapping system then if a RPKI repository publication [1] point is
> compromised (or even MiTM!) it would be a trivial exercise to perform some
> substitutions on the filename to confuse (routing security downgrade DoS)
> the relying party.
> 
> [1] Remember that the publication point is _just_ an rsync server (at this
> stage).

I personally feel uncomfortable on standardising a naming scheme from the dim dark prehistory of mainframe filesystems  as an intrinsic part of the RPKI - it seems so retrograde! I thought a BCP represented a slightly softer approach, but your question about the manifest contents and type flagging in there is an interesting approach. At one stage there was the though that the manifest would be optional for a CA, but somewhere along the path I think they were made mandatory, but in the forest of SIDR drafts I have no idea which one says that manifests are REQUIRED.

  Geoff