Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

Roque Gagliano <rogaglia@cisco.com> Thu, 10 November 2011 10:10 UTC

Return-Path: <rogaglia@cisco.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 7869321F8AD6 for <sidr@ietfa.amsl.com>; Thu, 10 Nov 2011 02:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.462
X-Spam-Level:
X-Spam-Status: No, score=-7.462 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f5OEPwdBCyO for <sidr@ietfa.amsl.com>; Thu, 10 Nov 2011 02:10:28 -0800 (PST)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 584E821F8AD1 for <sidr@ietf.org>; Thu, 10 Nov 2011 02:10:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=13741; q=dns/txt; s=iport; t=1320919807; x=1322129407; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=YWLTpJ1zhR0LSu7T118xS47je1qfGXqTUBaDvzqFPNE=; b=b6O6n0Fwxq/DLpF/G6bI7oGXkXterxigtFxXGNGaW0KuWgSddm+tAYGf X8OA/xDoVIY88MzzfV3TvorZ3OJ7jxe0pXM6AEj67QgPmivzKsblMwTBa KS5FuetngMJQoJm8Mh4j7+tLqEtYOLdEzNUPQO5k2Wns5AXJ4dX5LnRkf w=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAPKhu06Q/khN/2dsb2JhbABCp1GCWoEFgXIBAQEDAQEBAQ8BNCcEBwULCxguAiUwBhMih2AImS0BkC6OQokbYwSUKJFz
X-IronPort-AV: E=Sophos; i="4.69,488,1315180800"; d="p7s'?scan'208"; a="2792332"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 10 Nov 2011 10:10:05 +0000
Received: from ams3-vpn-dhcp6666.cisco.com (ams3-vpn-dhcp6666.cisco.com [10.61.90.9]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAAA9x7N032045; Thu, 10 Nov 2011 10:10:01 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary="Apple-Mail-75--984785135"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Roque Gagliano <rogaglia@cisco.com>
In-Reply-To: <7041B49A-6675-4010-B506-435AE2B7BF4C@tcb.net>
Date: Thu, 10 Nov 2011 11:09:49 +0100
Message-Id: <DCE90929-1BF6-4814-A640-784CF2979060@cisco.com>
References: <Pine.WNT.4.64.1110201037470.4820@SMURPHY-LT.columbia.ads.sparta.com> <7041B49A-6675-4010-B506-435AE2B7BF4C@tcb.net>
To: Danny McPherson <danny@tcb.net>
X-Mailer: Apple Mail (2.1084)
Cc: Sandra Murphy <Sandra.Murphy@sparta.com>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 10 Nov 2011 10:10:29 -0000

Danny,

Thank you for your comments and please see the response to your comments. Sorry for the delay.

Roque.

> 
> On Oct 20, 2011, at 10:50 AM, Sandra Murphy wrote:
> 
>> The authors have requested a WG LC for draft "Algorithm Agility Procedure for RPKI."
>> 
>> The document and the draft version history are available at
>> http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03
>> 
>> The last call will end Thu, 3 Nov 2011 (AOE).
> 
> 
> ---------------------------------------
> Substantial;
> 
> ---
> In S 4.6  (Phase 3) you state that all signed product sets are available
> using both algorithms and all RPs MUST be able to validate using either 
> suite.  Further, you state that an object that validates using either 
> Algorithm Suite A or Algorithm Suite B MUST be considered valid, 
> but in the subsequent sentence it is "RECOMMENDED" that RPs utilize
> only Suite B for validation [throughout Phase 3].  
> 
> Is the recommendation you're making that if product sets are available 
> via both Algorithm Suite A and Algorithm Suite B then the Suite A product
> sets SHOULD NOT be validated by RPs in order to minimize processing 
> overhead and the probability of cryptographic vulnerabilities resulting
> in downgrade attacks? 
> 
> Or SHOULD NOT be validated by RPs unless Algorithm Suite B validation 
> failure occurs, then fallback to the Algorithm Suite A product set  
> should be considered?  Or something else?  S.6 guidelines provide "As 
> a general rule, the validation of signed objects using different 
> algorithm suites are independent and the RP MUST NOT keep any 
> relationship between the different hierarchies", which seems to be 
> in conflict with the recommendation above unless some implementation 
> optimization or minimization of vulnerability to downgrade attacks 
> is being contemplated?


The intention was to let the RP to try to use Alg B first to facilitate the transition. I agree with your that the text was not clear.

What about this new text for section 4.6?

"Phase 3 starts at the RP Ready Algorithm B Date.  During this phase,  all signed product sets are available using both algorithm suites and   all RPs MUST be able to validate them using either suite.  An object that validates using either Algorithm Suite A or Algorithm Suite B  MUST be considered valid. It is RECOMMENDED that, in preparation for Phase 4, RPs utilize Suite B as the first and preferred option for validation throughout this phase. Thus, for example, an RP SHOULD try to validate the sets of signed products retrieved from the Algorithm Suite B repository first. 
If this effort fails (relative to the local validation policy), the RP SHOULD revert to using the Algorithm Suite A repository."


For your second comment, it is clear that the RPKI system will be vulnerable to downgrade attacks until the process is completed (EOL date). I believe this is captured somehow in the Security Considerations section when it says: "The procedure described in this document will take months or years to complete an algorithm transition. During that time, the RPKI system will be vulnerable to any cryptographic weakness that may have triggered this procedure.".

We can add some specific text:
"During that time, the RPKI system will be vulnerable to any cryptographic weakness that may have triggered this procedure (i.e. downgrade attack)."

> 
> ---
> Whatever the recommended behavior, how would it also change in Phase 4
> (Twilight), where a RP MAY continue to validate signed product sets
> using Suite C (old)?  If there's a failure in validation of the 
> current algorithm then should it use the "old" objects?  You seem to 
> suggest in S.6 that this is fine, but not in S.4.7?
> 

(Roque) Would a simple reference to section 6 make the trick?


> I think some more explicit guidelines about what to do and what not 
> to do would be useful in both Phase 3 and Phase 4 behavior that aligns
> with S.6 and clarifies the above issues would be of benefit.

(Roque) Again, I can add a reference to S.6.

> ---
> Also, in S.6 it's not clear to me what you mean by "instance of a 
> product" and "instances of such products", did you mean "signed 
> product sets" or something else?  If the former, which I think you 
> did, then it would be really useful if this "MUST contain the same
> resources" was provided much earlier in the document. 
> 
> "A failure to validate one instance of a product, under either 
> algorithm Suite MUST NOT cause the RP to reject the other instance 
> of the product. Because both instances of such products MUST contain 
> the same resources, relying on either instance will yield the same
> outcome."

(Roque) I am fine on adding this text.

> 
> Whereas in Phase 4 both may not even exist, correct?  

(Roque) Correct but also in Phase 1 and of course Phase 0.

> ---
> And given the above, if they "MUST contain the same resource", yet 
> S.7 says revocations are handled independently (even though during 
> phase 2 and phase 3 the "two certificate hierarchies are designed to 
> carry identical information" -- what does this mean?), how do you \
> accomplish all of this in practice?

(Roque) As there are independent hierarchies, you handle independent CRLs for each CA. Unfortunately, CA software will have to handle this "pain".

> ---
> Perhaps it should be that if two hierarchies exist they should be 
> identical - however, this diverges from the guidance that algorithm
> suites must be independent and the RPs MUST NOT keep any relationship
> between the different hierarchies.  This applies to "fallback" 
> implementation behaviors as well, I guess...

(Roque) No "fallback" is specified. 

> 
> Also, general guidance that as long as "old" or Algorithm Suite C 
> data is considered in parallel to or IF "current" algorithm fails, 
> the cryptographic vulnerabilities that triggered the rollover in the 
> first place may well result in downgrade attacks.
> 

(Roque) Again, you are vulnerable until EOL and we can be more precise in the text in the Security Section as referred before.

> ---------------------------------------
> Minor nits:


(Roque) Thanks, all corrected for next version


Thanks again for your review.

Roque




> 
> ---
> S 3 Terminology 
> 
> -
> s/conventions use din examples/conventions used in examples/
> 
> -
> Two occurrences of this ("CA Y" & "CA Z"):
> 
> s/used in examples this document/used in examples in this document/
> 
> 
> ---
> S 4.2 Process Overview
> 
> -
> s/prohibit a CA issuing/prohibit a CA from issuing/
> 
> 
> ---
> S 4.7 Phase 4
> 
> s/figure describe a possible/figure describes a possible/
> 
> ---
> S 5
> 
> s/implementing a different resource classes/implementing different resource classes/
> 
> 
> ---
> S 11
> 
> s/set will not longer be valid/set will no longer be valid/
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr