Re: [sidr] RPKI: Are relying parties really supposed to validate DER encoding?

Martin Hoffmann <martin@opennetlabs.com> Fri, 11 January 2019 10:24 UTC

Return-Path: <martin@opennetlabs.com>
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 3745412DF71 for <sidr@ietfa.amsl.com>; Fri, 11 Jan 2019 02:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnekk9j26UCS for <sidr@ietfa.amsl.com>; Fri, 11 Jan 2019 02:24:19 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC83F12D7EA for <sidr@ietf.org>; Fri, 11 Jan 2019 02:24:18 -0800 (PST)
Received: from glaurung.nlnetlabs.nl (unknown [IPv6:2a04:b900:0:1:a2c5:89ff:feb5:e311]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 77DB523210; Fri, 11 Jan 2019 11:24:14 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Date: Fri, 11 Jan 2019 11:24:13 +0100
From: Martin Hoffmann <martin@opennetlabs.com>
To: Alberto Leiva <ydahhrk@gmail.com>
Cc: sidr@ietf.org
Message-ID: <20190111112413.47060ed7@glaurung.nlnetlabs.nl>
In-Reply-To: <CAA0dE=X-hjb8UY6Gm_QJP+Vwqp5d8ho6rjYxZ4vSVF9SctAN_g@mail.gmail.com>
References: <CAA0dE=X-hjb8UY6Gm_QJP+Vwqp5d8ho6rjYxZ4vSVF9SctAN_g@mail.gmail.com>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.2 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/hi1gZN1e50yYbSCIxf3aXl4Sx3A>
Subject: Re: [sidr] RPKI: Are relying parties really supposed to validate DER encoding?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 11 Jan 2019 10:24:21 -0000

Alberto Leiva wrote:
> Hello.
> 
> I have a question:
> 
> RFC 6488 section 3.1.l (https://tools.ietf.org/html/rfc6488#section-3)
> wants relying parties (RPs) to validate that all RPKI signed objects
> are DER-encoded, which (I think) means that they must be BER-encoded
> with minimal and unique representations.
> 
> But I have found at least one other requirement that seems to
> contradict this: RFC 6482 section 3.3, fourth paragraph, second half,
> claims that a ROA (which is a signed object) is allowed to contain
> redundant ROAIPAddress elements.

DER is only concerned with encoding, not with the content. Mostly,
it forbids indefinite length constructed values and enforces string
types to be primitively encoded.

Unlike X.680, X.690 is actually quite readable. All of them are now
available for free from the ITU.

That all said, be warned that at least two RIRs currently produce RPKI
signed objects that are not validly DER encoded, but rather seem to be
using CER. So in practice, you will need to be able to parse the more
generic BER at least at this time or loose a significant part of the
RPKI repository.

For Routinator, we decided to have a relaxed validation mode and
documented all it does[0]. Currently, be default we run in relaxed mode
and have a command line option for strict mode.

Not sure if the working group needs to address this issue or how.

Kind regards,
Martin

[0] https://github.com/NLnetLabs/rpki-rs/blob/master/doc/relaxed-validation.md