Subject: [icnrg] recursive key Lookup in CCNX

From: Ken Calvert <[email-masked]>
Date: Sun, 26 Apr 2020 19:36:48 -0400

Why is recursive key lookup prohibited in CCNx 1.0?

I am really surprised that Section 8.1 of RFC 8569 says "we do not allow for recursive key lookup".

First, this seems to dictate a single policy for all applications using the CCNx network layer. That seems like a Big Deal, so I would expect to see some reason given in the RFC, but there's no justification.

I always thought being able to just "turn the crank" and retrieve the key that signed a content object,then the key that signed that, and so on (as long as the names match a trust schema, as described in the Yu et al ICN '15 paper) until you reach a trust anchor was one of the very best things about CCN/NDN.
What am I missing?

Related question:  What is the essential security difference between an X.509 certificate and a KeyLink?  If there's no difference, why require that trust chains be of length one, and end in X.509 certs (or known keys)?  And if there is a security difference, why define a separate Key object at all?

Thanks,

Ken

---

From: Ken Calvert <[email-masked]>
Date: Mon, 27 Apr 2020 12:51:30 -0400

> Related question:  What is the essential security difference between an X.509 certificate and a KeyLink?  

Correction: s/KeyLink/Key/, i.e., a signed content object containing a Key

> If there's no difference, why require that trust chains be of length one, and end in X.509 certs (or known keys)?  And if there is a security difference, why define a separate Key object at all?

---

From: Marc Mosko <[email-masked]>
Date: Mon, 27 Apr 2020 17:32:55 +0000

Ken,

It's at the end of Sec 8.4, not 8.1.  

Recursive link traversal has several issues.  The main one is loops and another is if there is a maximum length of a chain.  Specifying the validation process for recursive key / certificate lookup is not simple, especially if one does not include publisher public key restrictions.  Given that CCNx does not allow for prefix-matching on names, it is not so simple to create a system of looking up the current certificate for a content object using get-latest-version.  One needs to use expiry dates so the content object expires at or before the certificate expires and re-publish the content object, in which case one can update the KeyLink at the same time.

We do not require the trust chain to be of length 1.  We require the certificate retrieved by the keylink to be self-contained.   The certificate can have as many signers as one desires.  Also, the KeyLink could point to a segmented or manifest-based object, in which case the retrieval is not specifically 1 operation, but it is 1 security indirection step.

8569 says that trust is out-of-scope for the document.  Thus, we allow, by exclusion, other mechanisms the determine what is a trusted key.  If that mechanism includes network operations, that is ok.  So if you have a key lookup mechanism to fine the trusted keys for a namespace, that's ok.  This process should also specify how one revokes trust too.  If one specifies a trust scheme that needs to update RFC8569, then that's ok.

Also, the spec essentially recommends the process in section 8 as the Consumer behavior (Sec 2.2) by saying the consumer "SHOULD cryptographically verify the signature as per Section 8."  There are some reasons why a consumer should not use section 8.  For example, a manifest that the consumer trusts has a hash pointer to a content object with an untrusted or expired validation section.  The consumer does not need to (and probably should not) apply section 8 to the hash-pointed-to object.

We also recommend that the KeyLink use a content object hash restriction in the link.  In that case, it does not make much sense to have multiple hops as they cannot change.  One could also use the publisher key id restriction for a less-restrictive means, but it is less secure.

Finally, we wanted to have a correct validation process specified in the document that is spelled out in detail.  In Sec 8.4, we specifically limit a KeyLink to point to a Certificate (whereas before it could point to raw public keys too).

See "Trust in Information-Centric Networking: From Theory to Practice" [https://doi.org/10.1109/ICCCN.2016.7568589] for some details on why.

In relation to NDN, my understanding is that their certificate format also does not allow indirection (http://named-data.net/doc/ndn-cxx/current/specs/certificate-format.html).  It is not 100% clear from the NDN spec, but the description of KeyLocator says it is a "name that points to another Data packet containing certificate or public key" (or it's a KeyDigest).  If the certificate is non-recursive, I think you have pretty much the same situation as RFC8569, modulo name prefix matching.  Though it is not clear if that retrieved object could have its own KeyLocator, though I do not know why it would have one.  I am not aware of place where NDN specifies the recursive verification process (or even the non-recursive case) outside of the code, but would I like to know if someone has that pointer.

Marc

On 4/26/20, 4:37 PM, "icnrg on behalf of Ken Calvert" <[email-masked] on behalf of [email-masked]> wrote:

    Thanks,

    Ken
    _______________________________________________
    icnrg mailing list
    [email-masked]
    https://www.irtf.org/mailman/listinfo/icnrg

---

From: Ken Calvert <[email-masked]>
Date: Thu, 30 Apr 2020 21:28:54 -0400

Marc - 

> It's at the end of Sec 8.4, not 8.1.  

Right, thanks, sorry.

I've responded to your points below off-list, but here I'll just say that I remain unconvinced:  RFC 8569 declares trust out of scope, but then proscribes recursive key lookup.  To me, the latter places an undue constraint on how applications can deal with trust.  But I realize I am years late to this party, and I'm not a security expert.

I did not find any discussion of this issue in the mailing list archives (pointers welcome if I missed it or if it was discussed at any of the meetings).  I note that the explicit prohibition of recursive key lookup first appears in the RFC, and was NOT in any of the internet drafts - although the idea that a content object returned for a KeyLink should contain an X.509 certificate was there from the beginning.

I am wondering if I'm the only one who cares about this.

Cheers,
Ken

---

From: Marc Mosko <[email-masked]>
Date: Fri, 1 May 2020 02:01:16 +0000

Ken,

I will take a look at your email.

Here's another take an explaining it.  In section 8.4, we needed to explain a detailed method to validate a content object.  In the end, we decided that having a method to off-load the x.509 certificate (and its public key) to a second content object was desirable.  But, we did not want to go deep into all the what-ifs that happen with recursive lookup via links.  So, we settled for 1-step of indirection.  It would be perfectly reasonable for someone to say, "I have a system for resolving certificates via multiple links and here's an algorithm I can prove is correct and safe."  That would be great.  At the time of writing the RFC, we did not have such an algorithm and we did not want to leave content object verification to the imagination of anyone trying to use the protocol.

Another perfectly acceptable alternative is to propose your own ValidationAlgorithm that supports recursive KeyLink.  The IANA requirements for getting an assigned ValidationAlg number is "Specification Required" (https://tools.ietf.org/html/rfc8126#section-4.6), which is a pretty low bar.    Anyone can specify such a ValidationAlgorithm, get a number, and start using their validation algorithm with recursive KeyLink.

One can also use an Experimental validation algorithm without any review in your own testbed.

Let me also try to disentangle some terminology.  In CCNx, we use actual x.509 certificates in the payload of a content object.  We are not making a "certificate-like-thing" from the signing of a content object that has a public key.  I could see in that later case how recursive KeyLink fields would be useful, but that is not what we do.  It's a true X.509 certificate.  There is no reason to have recursive KeyLinks because the signing key of the 2nd object must be the same as the first object and the embedded X.509 certificate must match the same public key.  The 1-step indirection is simply to save space in a content object using x.509 certificates and allow caching of those credentials independently of other content objects.

NDN, over the years, has evolved their own certificate format and maybe they use recursive KeyLocator fields, I do not know.

marc

On 4/30/20, 6:29 PM, "Ken Calvert" <[email-masked]> wrote:

    Marc - 

    Right, thanks, sorry.

    Cheers,
    Ken