[sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS)

"Terry Manderson" <terry.manderson@icann.org> Wed, 18 November 2015 02:09 UTC

Return-Path: <terry.manderson@icann.org>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2F1B37D9; Tue, 17 Nov 2015 18:09:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Terry Manderson <terry.manderson@icann.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151118020907.790.34242.idtracker@ietfa.amsl.com>
Date: Tue, 17 Nov 2015 18:09:07 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/2Anj9G46Q9zeiU37HM1WFg9Lh5w>
Cc: sidr@ietf.org, draft-ietf-sidr-rfc6485bis@ietf.org, sidr-chairs@ietf.org, sandy@tislabs.com
Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 18 Nov 2015 02:09:07 -0000

Terry Manderson has entered the following ballot position for
draft-ietf-sidr-rfc6485bis-04: Discuss

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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm not so sure that this will be an easy DISCUSS to work through as I
view this in light of future sustainability/deployability of RPKI and any
protocol wedded to it (eg BGPSEC).

Section 5 "Additional Requirements" suggests that both CAs and RPs
"SHOULD" be capable of supporting a transition and thus able to support
multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it
invites fragility in any such transition. An immediate example would be
the root DNSSEC ksk rollover. An rather large amount of work is underway
to ascertain the impact. By leaving the SHOULDs in place is this walking
the same path? 

Let me ask another way. Under what situations is it actually appropriate
for a CA or RP to be able to ignore the requirement of being able to
support a phased introduction/deprecation of new/different RPKI algorithm
and key profiles? And if they ignore such a recommendation does this make
the entire RPKI infrastructure a fractured PKI by algorithm?