[sidr] come on people Re: The question about https certificates and frequency of mft/crl re-issuance

Sandra Murphy <sandy@tislabs.com> Thu, 09 June 2016 02:37 UTC

Return-Path: <sandy@tislabs.com>
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 96FC712D12F for <sidr@ietfa.amsl.com>; Wed, 8 Jun 2016 19:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HIGreDUhbVBa for <sidr@ietfa.amsl.com>; Wed, 8 Jun 2016 19:37:08 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98F512B029 for <sidr@ietf.org>; Wed, 8 Jun 2016 19:37:07 -0700 (PDT)
Received: from nova.tislabs.com (unknown []) by walnut.tislabs.com (Postfix) with ESMTP id 3BDEA28B0040; Wed, 8 Jun 2016 22:37:07 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain []) by nova.tislabs.com (Postfix) with ESMTP id 350491F805A; Wed, 8 Jun 2016 22:37:07 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_782EC7F3-C922-4A2C-ADD2-C001462474F5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.2
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net>
Date: Wed, 08 Jun 2016 22:36:18 -0400
Message-Id: <6B1254FF-8A81-4923-BBE6-12536C6001C9@tislabs.com>
References: <1CD27ACC-F5D2-4F11-8DD5-2B1F42544406@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/oSl-EMXwnuUX-8EqvmMD-QHvs8I>
Cc: sidr <sidr@ietf.org>, Sandra Murphy <sandy@tislabs.com>
Subject: [sidr] come on people Re: 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: Thu, 09 Jun 2016 02:37:09 -0000

Tim’s been waiting very patiently for any response to this.

The discussion was energetic and lots of people commented during the meeting and Tim promised to bring it to the list.

Where it looks like it is dying.  Those people who were speaking at this mike so energetically should be responding.

—Sandy, speaking as one of the wg co-chairs and nagger

On Apr 4, 2016, at 6:51 PM, Tim Bruijnzeels <tim@ripe.net> wrote:

> 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.
> Tim
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr