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/
- [sidr] WGLC for draft-ietf-sidr-algorithm-agility… Sandra Murphy
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Arturo Servin
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Paul Hoffman
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Samuel Weiler
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Danny McPherson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Roque Gagliano
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Randy Bush
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Stephen Kent
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Brian Dickson
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Sean Turner
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Christopher Morrow
- Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agi… Eric Osterweil