Subject: [sidr] Fwd: New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt

From: Richard Hansen <[email-masked]>
Date: Mon, 09 Mar 2015 21:07:49 -0400

Hi all,

I have submitted a bis of RFC6487 as a -00 individual submission, and
will be presenting it in Dallas.

It's a minor change from RFC6487.  Changes incorporated:
  * all 3 verified errata
  * RFC 7318 (update)
  * two changes that were submitted as errata but rejected for being
    technical changes:
    http://www.rfc-editor.org/errata_search.php?rfc=6487&rec_status=9

Comments welcome.

Thanks,
Richard

-------- Forwarded Message --------
Subject: New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt
Date: Mon, 09 Mar 2015 15:56:48 -0700
From: [email-masked]
To: Richard Hansen <[email-masked]>, Andrew Newton <[email-masked]>,
Robert Loomans <[email-masked]>, Geoff Huston
<[email-masked]>, George Michaelson <[email-masked]>

A new version of I-D, draft-rhansen-sidr-rfc6487bis-00.txt
has been successfully submitted by Richard Hansen and posted to the
IETF repository.

Name:		draft-rhansen-sidr-rfc6487bis
Revision:	00
Title:		A Profile for X.509 PKIX Resource Certificates
Document date:	2015-03-09
Group:		Individual Submission
Pages:		32
URL:
http://www.ietf.org/internet-drafts/draft-rhansen-sidr-rfc6487bis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-rhansen-sidr-rfc6487bis/
Htmlized:       http://tools.ietf.org/html/draft-rhansen-sidr-rfc6487bis-00

Abstract:
   This document defines a standard profile for X.509 certificates for
   the purpose of supporting validation of assertions of "right-of-use"
   of Internet Number Resources (INRs).  The certificates issued under
   this profile are used to convey the issuer's authorization of the
   subject to be regarded as the current holder of a "right-of-use" of
   the INRs that are described in the certificate.  This document
   contains the normative specification of Certificate and Certificate
   Revocation List (CRL) syntax in the Resource Public Key
   Infrastructure (RPKI).  This document also specifies profiles for the
   format of certificate requests and specifies the Relying Party RPKI
   certificate path validation procedure.

   This document obsoletes RFC 6487.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Sean Turner <[email-masked]>
Date: Thu, 19 Mar 2015 18:22:40 -0400

> It's a minor change from RFC6487.  Changes incorporated:

Faithfully includes the errata I submitted ;)

>    http://www.rfc-editor.org/errata_search.php?rfc=6487&rec_status=9

I’ll caveat this by saying I am definitely not hard over on this, but I thought I’d bring it up: Should we switch to a SHA-256-based key identifier?

s4.8.3 includes the following text:

  The Key Identifier used for resource certificates is the 160-bit
  SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
  issuer's public key, as described in Section 4.2.1.1 of [RFC5280].

Well now there’s RFC 7093 (http://datatracker.ietf.org/doc/rfc7093/) and we could point there and generate an identifier based on SHA-256.  Full disclosure: this would introduce a downref to the document; the RFC was published through the ISE.

spt

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Mar 2015 12:35:42 -0500

> I’ll caveat this by saying I am definitely not hard over on this, but
> I thought I’d bring it up: Should we switch to a SHA-256-based key
> identifier?

all the kool kids are doing that

randy

---

From: Robert Kisteleki <[email-masked]>
Date: Fri, 20 Mar 2015 20:48:25 +0100

> all the kool kids are doing that

That's nice, but can someone explain what the actual benefit would be?

Robert

---

From: Rob Austein <[email-masked]>
Date: Fri, 20 Mar 2015 16:20:41 -0400

At Fri, 20 Mar 2015 12:35:42 -0500, Randy Bush wrote:
> 
> > I?ll caveat this by saying I am definitely not hard over on this, but
> > I thought I?d bring it up: Should we switch to a SHA-256-based key
> > identifier?
> 

Not sure it's worth making an incompatible change.

The key identifier isn't used for integrity checks, it's just the name
of a sort of virtual hash bucket which we use as one of the criteria
for pruning irrelevant candidate objects before we get all the way to
doing expensive signature checks.  An attacker can achieve the same
effect just by inserting whatever attack string seems interesting in
the key identifier field, regardless of digest algorithm, unless
validation code also computes the key identifier digest itself and
checks that digest against the key identifier of the object under
inspection.

My understanding is that all the current validation implementations do
in fact check key identifier digests (mostly because BBN's creatively
evil test suite whines at us if we don't detect such errors), which is
both good and bad: it's good, because it makes the DoS attack
described above harder (more precisely, it trades a small increase in
the known fixed cost per object against the risk of the DoS attack),
but it's bad because all this code knows which digest algorithm we're
using to generate key identifiers and will care if we change that
algorithm, rather than treating key identifiers as an opaque blobs.

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Sat, 21 Mar 2015 10:10:13 +0000

>Not sure it's worth making an incompatible change.

We may be facing problems when trying to certify RPKI software inside real
customers. My experience with customers such as banks and some BGP
networks (think about SWIFT) is that their security check-list is
very-very hardcoded. If you have a non-compliance, it will delay your
project for months/years and will add a lot of grey hairs to the project
teams.

So, if SHA-1 is officially deprecated (or de-facto as it is happening now)
and makes it to these security-compliance check-lists, we will have no
alternative from a practical view if we want people to use the technology
(even if it does not introduce real enhancements.)

Roque