Subject: Re: [secdir] secdir review of draft-ietf-sidr-delta-protocol-05

From: Oleg Muravskiy <[email-masked]>
Date: Sun, 5 Feb 2017 13:44:22 +0100

Hi David,

Thanks for your review and comments, I'll try to address them below in the text:

> On 28 Jan 2017, at 22:29, David Mandelberg <[email-masked]> wrote:
> 
> Hi,
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> This document provides a new way for RPKI Relying Parties to download
> RPKI objects. As mentioned in the Security Considerations, those objects
> are already cryptographically signed. The RRDP protocol provides some
> additional security to the download process, with no changes to the
> security properties of the RPKI objects themselves.
> 
> I think this document is Ready with nits.
> 
> 
> 3.3.2: It seems strange to me that you use MUST when talking about the
> timing/performance of the repository server. Is this relevant to
> security? Or is there another reason for a MUST?

I do not think this time interval (less than 1 minute to publish updates for any CA) has a direct impact on the security. However, it'a also not about the performance of the publication server, but to guarantee the expectations on the staleness of the data in the repository, both from CA's and RP's point of view.
So I'd like to keep it a "MUST".

> 3.4.2: I think "update its last processed serial number to the serial
> number of this snapshot file" should say "delta file" instead.

Correct. Fixed in -06.

> 3.4.5: I'd recommend changing "in case of network issues" to "in case of
> network issues, or temporary failures of the repository server(s) or
> caching infrastructure".

I agree that "network issues" is only one possible cause. I'm not sure we could/should mention all of them in that paragraph, so I'll leave it with "Relying Parties may wish to employ re-try strategies while fetching RRDP files".

> 3.5.1.2: I think the last paragraph might make it harder for the server
> to recover from a temporary overload, since it can't tell clients to
> wait longer than 1 minute before re-fetching. It seems to me that
> letting the clients get a few minutes out of date until the server
> operator can provision more capacity is better than accidentally DoSing
> the server.

I think what we want to say here is that [for security reasons] RPs should not trust the HTTP caching headers for notification files, if they specify caching for longer than 1 minute, because those headers could be overwritten by the (CDN) distribution servers which might be out of control of the publication server operator.

One minute should be enough for a CDN to overcome DDoS anyway. Additionally, the If-Modified-Since: request header is mandatory, which also lowers the load on the server. And specifying 1 minute cache expiration on notification file does not mean an RP *will* come back for a new file after a minute.

So do you want a longer text in that paragraph?

> 3.5.4: Why is serial not an xsd:positiveInteger? Section 3.3.1 says that
> serials start at 1.

Correct. Fixed in -06.

Cheers,
Oleg

---

From: David Mandelberg <[email-masked]>
Date: Sun, 5 Feb 2017 12:23:19 -0500

> So do you want a longer text in that paragraph?

No, I think the existing text adequately explains what you're saying. I
still think it's excessive to poll every 1 minute without honoring
headers that say to wait longer*. But I don't think it's a security
issue, and I don't think my opinion on this should delay publication.

* I was aware of the issue you described where RPs should not trust
unverified headers, so I'm not advocating for unconditional trust of the
headers. I just think the RPs should trust the caching headers up to,
maybe, 1 hour instead of 1 minute. But even 5 minutes would give CDN
operators a lot more leeway to shed load.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Oleg Muravskiy <[email-masked]>
Date: Wed, 8 Feb 2017 12:04:49 +0100

Hi everybody,

> On 05 Feb 2017, at 18:23, David Mandelberg <[email-masked]> wrote:
> 

Reading the paragraph in question again:

   Relying Parties SHOULD NOT cache the notification file for longer
   than 1 minute, regardless of the headers set by the repository server
   or CDN.

I think it could be misinterpreted in a way that RP should re-fetch notification file even if being in a middle of a validation run, which is wrong. So I propose a new text:

  In case of a high load on a repository server or its distribution
  network, the Cache-Control HTTP header, or a similar mechanism, MAY
  be used to suggest an optimal (for the repository server) poll
  interval for Relying Parties. However, setting it to an interval
  longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align
  the suggested interval with their operational practices and the
  expected update frequency of RPKI repository data, and MAY discard
  suggested value.

What do you think?

Oleg

---

From: David Mandelberg <[email-masked]>
Date: Sat, 11 Feb 2017 13:42:39 -0500

>   expected update frequency of RPKI repository data, and MAY discard

I'm ok with the new text.