Re: [icnrg] Technical question on CCNx Specs

[Ken Calvert <[e-mail]>]

Hi Marc - 

Thanks for the speedy clarification.  I agree that leaving the TL outside the validation region is basically harmless.

Ken 

> On 22 Apr 2020, at 13:13 PM, Marc Mosko <[e-mail]> wrote:
> 
> 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
>