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

[Oleg Muravskiy <[e-mail]>]

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 <[e-mail]> 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