[sidr] The question about https certificates and frequency of mft/crl re-issuance

Tim Bruijnzeels <tim@ripe.net> Mon, 04 April 2016 22:51 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 170E312D8E6 for <sidr@ietfa.amsl.com>; Mon, 4 Apr 2016 15:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fcS47GdMt7CQ for <sidr@ietfa.amsl.com>; Mon, 4 Apr 2016 15:51:37 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [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 ietfa.amsl.com (Postfix) with ESMTPS id AA5A712D8EA for <sidr@ietf.org>; Mon, 4 Apr 2016 15:51:37 -0700 (PDT)
Received: from nene.ripe.net ([]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1anDLK-000BMJ-56 for sidr@ietf.org; Tue, 05 Apr 2016 00:51:35 +0200
Received: from sslvpn.ripe.net ([] helo=vpn-175.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1anDLJ-0001zI-N7; Tue, 05 Apr 2016 00:51:33 +0200
From: Tim Bruijnzeels <tim@ripe.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 Apr 2016 19:51:29 -0300
To: sidr <sidr@ietf.org>
Message-Id: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197a303304442343a2e96fc6b73b2918dd
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/ePQ1zg7934EmOfKmCSVrmzVXw64>
Subject: [sidr] The question about https certificates and frequency of mft/crl re-issuance
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 04 Apr 2016 22:51:39 -0000

Hi all,

I promised to take this to list.

So, as presented today, the volume of updates of MFTs and CRLs in the RIPE NCC repository vs updates of ROAs is about 1000:1. This is a bad signal -to-noise ratio that causes waste of cycles and bandwidth.

= Why this noisy? MITM..
We get this, because we use a 'next update time' of 24 hours, but we actually republish every 8 hours to make sure that we can fix issues before things go stale. In my understanding we need this because of man-in-the-middle attacks involving replay or withhold. And rsync is vulnerable to this (clear text, and no authentication of server). If an RP is being fed old data, they would notice that something is wrong within 24 hours. A longer period seems scary.. If this understanding is wrong I would love to be educated.

= Solved by https?
But assuming this does make sense, I wondered whether RRDP with httpS offers a way out of this. With RRDP a CA signs a certificate with an https URL like: https//my.repository.example.org/notification.xml. We can trust this because it's on a signed certificate. Now, if we can also exclude mitm, because we can trust the httpS certificate, this would allow for a much longer period 'next update time'. And in the meantime the RP would still learn about updates before this, because the notification.xml is checked regularly and would include any changes ahead of this.

= If so, how to handle https TAs?
This is a question for RPs. But trusting all https certificates or all default TAs configured on a system is potentially problematic if the CA assumes that RPs check against mitm. Some of the many TAs preconfigured in browsers have been shown to have issues here.

Then again, RP software could be pre-configured with a smaller set of TAs or even server certificates for know repositories and offer an interface to operators to change this set. Or RPs could accept new certificates for repositories, but require operators to confirm changes. The number of expected repositories isn't great. But there clearly are scaling issues here.

As I stated on the mic. I don't claim to have the answer. But I think it's really worth thinking about ways to reduce the signal-to-noise ratio mentioned.