Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Thu, 16 February 2017 22:50 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEFF129632; Thu, 16 Feb 2017 14:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL68ur462uBJ; Thu, 16 Feb 2017 14:50:39 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807CE124281; Thu, 16 Feb 2017 14:50:39 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v1GMobWW043386 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Feb 2017 16:50:38 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: Ben Campbell <ben@nostrum.com>
To: Tim Bruijnzeels <tim@ripe.net>
Date: Thu, 16 Feb 2017 16:50:36 -0600
Message-ID: <8B6A4F38-3C47-4EA2-92FC-BCA71EFEB947@nostrum.com>
In-Reply-To: <6FE13EA4-CFDF-4FF0-BC4C-88CE7323571A@ripe.net>
References: <148721586667.31507.17178698587667640093.idtracker@ietfa.amsl.com> <6FE13EA4-CFDF-4FF0-BC4C-88CE7323571A@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5344)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/JOPl-1cDXdgSByDslJtylWKY4eI>
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, The IESG <iesg@ietf.org>, sidr@ietf.org, draft-ietf-sidr-delta-protocol@ietf.org
Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)
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, 16 Feb 2017 22:50:41 -0000

Hi, thanks for the response. Please see comments inline.

Thanks!

Ben.

On 16 Feb 2017, at 8:31, Tim Bruijnzeels wrote:

> Dear Ben, all,
>
>
>> On 16 Feb 2017, at 04:31, Ben Campbell <ben@nostrum.com> wrote:
>>
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-sidr-delta-protocol-07: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this
>> introductory paragraph, however.)
>>
>>
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> - 3.4.1, 3rd paragraph: In a number of other protocols, a 
>> "User-Agent"
>> header can be used for implementation fingerprinting, so that an 
>> attacker
>> can guess what vulnerabilities might exist in that instance. Is that 
>> a
>> concern here?
>
> TL;DR:
>
> This is not strictly required by the delta protocol and can be taken 
> out if big concerns exist. But I believe that this will help with 
> operational planning of changes in RPKI standards. I do not see big 
> security concerns - obviously if I did I would not have insisted to my 
> co-authors that we should have this :)
>
> Longer:
>
> The "User-Agent" was introduced here solely to help capability 
> tracking that may help in operations of *other* changes in the RPKI 
> standards.
>
> For example: validation-reconsidered introduces new OIDs that when 
> present will lead to current RPs rejecting objects that use them. If 
> this happens at the trust anchor level that can be problematic. 
> Because of this, the reconsidered document includes an intended 
> timeline where RP software MUST be updated with this capability before 
> CAs MAY use this. A timeline is one way to do this, but being able to 
> also actually track if updated RP software is really deployed is 
> useful.
>
> Similarly capability tracking can help with other (currently 
> unplanned) changes in the RPKI: new object types, or changes to 
> existing ones. And it can help if we ever need to do an algorithm 
> roll-over, e.g. to elliptic-curve instead of RSA - then again knowing 
> which proportion of RPs supports the new algorithm can help.
>
> On the other hand I do not see a huge security concern with this 
> because even though Repository Servers would know which version of RP 
> software is deployed where, they would not be able to attack them 
> easily because RPs can normally be contacted only inside the trusted 
> network where they are operated: e.g. routers using rpki-rtr.

There is a mention in the security considerations that the repository is 
not trusted.

I recognize the risk is not high. Making User-Agent a SHOULD is not my 
favorite thing, but I'm not going to push the point. Do I understand 
correctly that RRDP is only defined for use with TLS? (Did I miss a MUST 
NOT use without TLS requirement)? If there's any chance of using this 
without TLS, then it might be worth a security consideration mention.


>
>> - 3.5.3.2, 2nd paragraph: The MAY sounds more like a statement of 
>> fact
>> than permission.
>
> yes, but whether the files *are* cached is a choice, so I thought a 
> normative MAY was in order. I don't particularly mind changing this 
> though, because I don't think it will lead to ambiguity.

My point is the fact people can do that is natural outcome of the fact 
the files do not change. You aren't offering permission so much as 
noting the possibility. But I will leave the choice to you.

>
>>
>> - 5.2, 2nd paragraph: The RECOMMENDED sounds like a statement of fact 
>> as
>> worded.
>>
>
> I am not sure that I understand your comment.
>
> We RECOMMEND that RP software polls the Update Notification File for 
> changes. We believe that is useful to mention here because new 
> implementations may find it useful and it sends a message to 
> Repository Servers that they should be prepared to deal with this.
>
> However, another strategy can also be used. For example the current 
> RIPE NCC RPKI Validator will actually re-trigger a complete validation 
> process every X (configurable) minutes and then try to fetch updates. 
> This works, but is somewhat resource intensive for the RP.
>
> Would it be better if we did not RECOMMEND, but rather said something 
> like this?
>
> RPs MAY poll the Update Notification File for changes, so that a 
> potentially resource intense RPKI validation process can be avoided if 
> there is no new content available.

So this is was just a very pedantic NIT about the use of 2119 keywords, 
where the sentence makes it sound like the fact of the recommendation 
comes from some authority other than the sentence itself. But on 
re-reading it, I don't think it creates ambiguity. It's probably not 
worrying about.