Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Rob,

On 2022-04-22, at 11:14, Rob Wilton (rwilton) <rwilton=[e-mail]> wrote:
> 
> Hi Carsten,
> 
> One other thought on this (when I was out running this morning) …

Thank you for spending some of your running cycles on this — this class of cycles is precious (I'm not a running type, so CBOR was almost entirely designed under the shower).

> if C often does use strcpy (or even strncpy), then avoiding the zero byte isn't the only problem, it also has the risk of capturing arbitrary extra bytes which would presumably make the magic number check less reliable?

That is easily avoided by using strncpy(dst, buf, 8).
But that is advice we maybe don’t want to give (see below).

> My instinct here is that we keep the algorithm simple, don't avoid embedded zero bytes, don't zero terminate, and just state that robust implementations should not assume that the magic number is a null terminated string.  

We were assuming that some people would want to *store* it in a null-terminated string (after obtaining that using the strncpy processing above).

> Specifically, I'm assuming that C using strncpy isn't a security issue (because they don't know whether a file contains a magic number at all), just a reliability one, and that implementations will hopefully realize and fix this over time.  But this is just my opinion/suggestion.

I would love to hear more opinions out of the WG here.

My current state of mind is that we maybe fell into an analogon of the Postel Principle trap [1].
By anticipating how people will want to be lazy when implementing this, we may be *too* “conservative in what we send”.

But then, making life easy for implementers is important, and so making the first 8 bytes compatible with being stored in a C string may also be an appropriate accommodation.

Grüße, Carsten

[1]: https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/

PS.: I wrote

>> This is easy to fix by using
>> 
>> 0x63740000 + (ct / 255 + 1) * 256 + ct % 255 + 1
>> 
>> as the tag number (*).

More readable version (and entirely obvious in this form):

0x63740101 + (ct / 255) * 256 + ct % 255
where the content-format number ct < 255*255.