Re: [icnrg] Technical question on CCNx Specs

[Marc Mosko <[e-mail]>]

Ken,

RFC 8569 does not imply any particular encoding mechanism, like the TLV form of 8609.  So, 8569 will not make distinctions about TLV headers.  One could be using S-expressions or a fixed order length encoding or JSON.  Each particular encoding would need to say what it means to be a field.

In terms of RFC 8609, a field, like ValidationPayload, is all three of the T, L, and V.  The value of the field is just the V.  So, for validation in specific, the protected region begins with the CCNx Message "T" and ends with the last byte of the ValidationAlgorithm "V".  The entire ValidationPayload TLV is not included.

Let's look at what this means.

1) The "T" must be T_VALIDATON_PAYLOAD.  If it is anything else, it is either skipped or there's no validation payload to compare and the check would fail.
1.1) I believe it is possible for someone to insert a T_ORG or T_PAD between the validation algorithm and validation payload.  This would be outside the validation region but still considered part of the PacketPayload TLVs (8609, Sec 3.1).  A T_PAD would be skipped.  A T_ORG would be optionally processed if one knows how to process it and one expects it to be there.
2) If the "L" is not correct, the validation will fail.  
2.1) Someone could shorten the L, in which case there are not enough bytes to match so the check fails.
2.2) Someone could lengthen the L, in which case it would run past the end of the packet and the check would fail due to illegal formatting.  Someone could also increase the fixed header PacketLength, but that would also run past the end of the received datagram, so that would fail due to illegal formatting without even getting to the validation check.  Or, there's just more bytes than the expected validation payload and the check fails.
3) Someone changes the V.  Well, that's the point of the validation algorithm, so hopefully the check would fail for any good validation algorithm.

So, if someone changes the T and L, the check fails.  

8609, Sec 3.3.3 allows hash values to be left truncated to specific sizes.  In specific, a T_SHA-512 could be sent as a 32-byte version.  However, all important hash values are inside the validation region, so they cannot be changed.  If a producer decides to send a T_SHA-512 as 32-bytes, that's their usage.  Sec 3.3.3 does not allow, for example, an HMAC output to be truncated.

Marc

On 4/22/20, 8:59 AM, "icnrg on behalf of Ken Calvert" <[e-mail] on behalf of [e-mail]> wrote:

    Folks -
    
    I am implementing a CCNx forwarder from RFCs 8569 and 8609, as a way of understanding the protocol; as a side effect it is a test of the specs.
    
    I have a nitty-gritty (but simple) question I can't resolve with the RFCs.  I'd prefer not to look at other implementations, so I'm asking it here.  It's about the what is covered by the signature (or whatever mechanism is used).
    
    Section 8.1 of 8569 says:  "The validation is calculated from the beginning of the CCNx Message through the end of the ValidationAlgorithm section (i.e., up to but not including the validation payload).  We refer to this as the validation region.  The ValidationPayload is the integrity value bytes, such as a MAC or signature."
    
    There is an ambiguity here regarding what constitutes the "validation payload" (vs. "ValidationPayload", sic).  My question is whether the first 4 bytes (type + length) of the Validation Payload TLV are part of the validation region (i.e., covered by the signature, HMAC, CRC, or whatever).  RFC 8609 (Section 3.6.4.1) says  that the Validation Payload TLV is NOT part of the ValidationAlgorithm TLV.  So the first sentence quoted above seems to say that its header is NOT covered, while the last sentence (as well as common sense about security) would lead one to think that it IS covered.
    
    Thanks for any hints.
    
    Ken
    
    
    _______________________________________________
    icnrg mailing list
    [e-mail]
    https://www.irtf.org/mailman/listinfo/icnrg