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

Danny McPherson <danny@tcb.net> Mon, 31 October 2011 00:59 UTC

Return-Path: <danny@tcb.net>
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 A67F721F84A6 for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 17:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level:
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 x86rLvwIEWib for <sidr@ietfa.amsl.com>; Sun, 30 Oct 2011 17:59:41 -0700 (PDT)
Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F221F849D for <sidr@ietf.org>; Sun, 30 Oct 2011 17:59:41 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 5BA771900B8; Mon, 31 Oct 2011 00:59:38 +0000 (UTC)
Received: from dul1dmcphers-m2.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 8589D320283; Mon, 31 Oct 2011 00:59:37 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <Pine.WNT.4.64.1110201037470.4820@SMURPHY-LT.columbia.ads.sparta.com>
Date: Sun, 30 Oct 2011 20:59:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7041B49A-6675-4010-B506-435AE2B7BF4C@tcb.net>
References: <Pine.WNT.4.64.1110201037470.4820@SMURPHY-LT.columbia.ads.sparta.com>
To: Sandra Murphy <Sandra.Murphy@sparta.com>, Steve Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: 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: Mon, 31 Oct 2011 00:59:42 -0000

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?

---
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?

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.

---
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."

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

---
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?

---
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...

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.

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

---
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/