Re: [sidr] two stranded docuemnts - stake time

Tim Bruijnzeels <> Mon, 01 August 2016 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E26F612D6AF for <>; Mon, 1 Aug 2016 07:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VUTC2IMNlhIV for <>; Mon, 1 Aug 2016 07:34:11 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4439212D672 for <>; Mon, 1 Aug 2016 07:34:11 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <>) id 1bUEI7-0004wf-3T; Mon, 01 Aug 2016 16:34:04 +0200
Received: from ([] by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <>) id 1bUEI6-0002b5-RR; Mon, 01 Aug 2016 16:34:02 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDE272FE-7059-4DCB-BE64-39C72ABD52D3"
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Mon, 01 Aug 2016 16:34:02 +0200
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Stephen Kent <>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --------
X-RIPE-Spam-Report: Spam Total Points: -8.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.0908]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f2d3dea43be4a524f36ced4a031d1f2c
Archived-At: <>
Cc: Chris Morrow <>, sidr <>
Subject: Re: [sidr] two stranded docuemnts - stake time
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: Mon, 01 Aug 2016 14:34:16 -0000


> On 01 Aug 2016, at 14:42, Stephen Kent <> wrote:
> Tim,
>> Although I appreciate that Randy is trying to explain the case in terms anyone can understand, it would be preferable to keep it general.
> agreed.
>>> (Including a parenthetical note about the historical precedent of a Dutch court order involving RIPE is relevant and might be included.)
>> If there was such a precedent, but there isn't. I have raised this before, but again...
> I am familiar with the incident. While it is true that the court did not order RIPE to do anything with RPKI data, the precedent it set has often been cited as an indication of what might happen in the future. That's why the adverse actions document identifies the following cause for some types of actions:
> There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to generate "bogus" signed objects or remove legitimate repository data.
> This is the sort of more formal language I have encouraged Randy to use in the LTA use cases doc, to no avail.

You will notice that I did NOT object to this being raised as a possibility as such.

I object to presenting a different case altogether as a precedent to support the impression that it's not a question of if, but when this will happen.

This is not constructive.

It would be lot more constructive to explain to law enforcers how such an action would be ineffective, and ultimately counter productive. Wording like this might help:

    Law enforcement would be ill-advised to take this cause of action as it will degrade the trust that
    operators place in the global RPKI. Not only can operators use local policy to circumvent the "bogus"
    objects - making it an ineffective measure, abuse of this power will also lead to operators choosing
    not to use RPKI at all. This in turn will mean that critical internet infrastructure will remain
    vulnerable to hijacks.

In short it should be made clear to "law enforcement" that there is no precedent, and that this is very much against their own interests. If they want to ban some traffic, there are much more reliable methods at their disposal, with much less collateral damage.