Re: [icnrg] recursive key Lookup in CCNX

[Ken Calvert <[e-mail]>]

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

> 
> 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" <[e-mail] on behalf of [e-mail]> wrote:
> 
>    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
>    _______________________________________________
>    icnrg mailing list
>    [e-mail]
>    https://www.irtf.org/mailman/listinfo/icnrg
>