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

From: Sandra Murphy <[email-masked]>
Date: Wed, 8 Jun 2016 22:36:18 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jun 2016 16:10:39 -0400

Tim,

Sorry to have not replied sooner.

> 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 be…
I think an 8-hour cycle is very much overkill, despite the good 
intentions that motivated it.

An RP should detect when a manifest is stale, since the manifest carries 
a next publication date. It's a local matter as to how stale a Manifest 
can be before an RP sounds an alarm. The actions an RP MAY take in the 
face of a stale Manifest are also largely a local matter, as per RFC 
6486. So, I don't think an 8-hour re-pub rate is warranted given these 
local policy aspects of Manifest processing.

Similarly, daily CRL publication strikes me as overkill as well. Yes, 
it's nice to be able to say that IF there were a need to revoke a cert, 
everyone could know about that in 24 hours. BUT, revocations in many 
PKIs are fairly rare, and in the RPKI they seem very infrequent as well, 
right?

I'd suggest a default next update frequency for both CRLs and Manifests 
of 1 week.
This should be shortened if a resource is about to be transferred, or 
there is a planned key rollover, etc. If we adopt 1 week as the default, 
then pushing out
new versions every 3-4 days would be reasonable, IMHO.

These changes would reduce churn by a factor of 10 or so.
> 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/notificat…
I'm not sure I understand the analysis above. In the current scheme, the 
next update times for CRLs and Manifests are signed objects too. yes, an 
RP could learn about an earlier update IF there is no attack that 
prevents timely dissemination of the notification file. But, what 
prevents an attacker from delaying such notifications?

I'll have to think about your TA questions some more before replying.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 24 Jun 2016 18:39:31 -0400

Look, if no one can summon the energy to respond, Tim has no way to decide on a change.

So the current direction will not change.

If you are one of those who were speaking at the mike, please consider typing at a keyboard.

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

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Jun 2016 09:32:56 +0200

> Look, if no one can summon the energy to respond, Tim has no way to

i believe that rob laid this out clearly many months ago.  and no, i
will not look it up for folk; the epicycles have become too painful.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sat, 25 Jun 2016 13:35:07 +0200

Hi,

> On 25 Jun 2016, at 09:32, Randy Bush <[email-masked]> wrote:
> 

I remember the comments, and I have been in contact with Rob and the other RRDP authors about this. I think we can move forward.

It is useful to separate the issues regarding 1) https certificate verification, and 2) mft/crl re-issuance.

On 1) .. 

In short, we seem to converge on using HTTPS certificate validation to alert about possible problems, but since RPKI objects are signed and can be validated even if the source is untrusted, let's always try to get the latest regardless. We are still working on the text, but the gist of what we would like to put in a -05 doc before the cut-off date:

4.  HTTPS considerations

  It is RECOMMENDED that Relying Parties and Publication Servers follow
  the Best Current Practices outlined in [RFC7525] on the use of HTTP
  over TLS (https).

  Note that a Man-in-the-Middle (MITM) cannot produce validly signed
  RPKI data, but they can perform withhold or replay attacks targeting
  an RP, and keep the RP from learning about changes in the RPKI.
  Because of this RPs SHOULD do TLS certificate and host name
  validation when they fetch from an RRDP Publication Server

  However, such validation issues are often due to configuration
  errors, or a lack of a common TLS trust anchor.  In these cases it
  would be better that the RP retrieves the signed RPKI data
  regardless, and performs validation on it.

  Therefore RPs SHOULD log any TLS certificate or host name validation
  issues they find, so that an operator can investigate the cause.  But
  the RP SHOULD continue to retrieve the data.  The RP MAY choose to
  log this issue only when fetching the notification update file, but
  not when it subsequently fetches snapshot or delta files from the
  same host.  Furthermore the RP MAY provide a way for operators to
  accept untrusted connections for a given host, after the cause has
  been identified.

On 2) CRL/MFT re-issuance

First of all. TL;DR on the below: There are operational considerations that I am happy to share with the group, but if they need to be documented it's not in the RRDP document.

I brought it up because there is some mention of using nextUpdate in CRLs and MFTs as a protection against replays, and I believe the above (under 1) provides a better way to detect this. The 24 hours that is now frequently used is probably way too long anyway to be useful w.r.t. MITM. So I don't think that changing it to 7 days, or even 1 month makes much difference in this regard.

The discussion that we may want to have is whether nextUpdate should be used as an indication of when to fetch data again. This keeps coming up. Steve Kent also suggested having a long default nextUpdate time, and a shorter one when we know that there are changes.

Problem is that the common case for change is unpredictable: a change in routing requires ROAs or BGPSec certificates to be re-issued, and there is a desire that RPs learn about this fast. There was a lot of discussion a few years ago about how fast.. especially Danny McPherson was vocal on this. There is no clear indication of what is fast enough though. My impression is that if changes in RPKI can propagate to RPs (and connected routers) in 10-30 minutes we are in a good spot.

Both rcynic and the RIPE NCC RPKI Validator* will re-fetch at regular intervals regardless of the nextUpdate time. With RRDP I believe we have the scaling to support refetching every 5-10 mins by any RP that wants it. But if we do, we need to lower the churn resulting from MFT/CRL updates.

So, I believe that it's safe to lower the nextUpdate frequency to something in the order of a week, or even a month. Chris Morrow brought up a concern about keeping the cogs in the machine well greased. I hear you, but in our case we have over 3000 hosted CAs, if we re-issue MFTs/CRLs every month we still smear the cogs with a 100 CAs every day.

Finally I also had another thought how we can lower the signal-to-noise ratio of MFT/CRLs vs ROAs in our operations. Currently we re-issue CRLs/MFTs for our 3000+ CAs every X hours, or whenever there is a change in ROAs (no BGPSec yet). We optimised to spread the load on our CPU and HSM. But if we want to optimise for RPs fetching instead, we can change our implementation to do the background CRLs/MFTs updates in large batches (say once per X days), and only do the ROA related updates as soon as they happen. This would allow RPs to aggressively do a cheap fetch for our update notification file every X minutes, and they would only find that they need to do an expensive when there are important changes - and okay once per X days because of the nextUpdates are re-newed.

Anyway, I believe that all of the above is in the space of local operational considerations. There may be merit in discussing, and we may find there is merit in documenting as Informational or BCP, but in my opinion not in the current RRDP document.

Cheers
Tim

*: off-topic.. yes, we need a cool name, ideas welcome ;)

---

From: Rob Austein <[email-masked]>
Date: Sat, 25 Jun 2016 14:47:20 -0400

I agree with Tim that:

a) We appear to be approaching closure on text to nail down the TLS
   certificate validation behavior of RRDP; and

b) That the MFT/CRL re-issuance implications of TLS certificate
   validation in RRDP (if any) are a separate topic to be discussed
   (if at all) in a different I-D.

I would add that we may not know enough to write the second I-D yet,
so I'm not in any particular hurry to start on it.