Re: [Cbor] I-D Action: draft-richardson-cbor-network-addresses-01.txt

[Carsten Bormann <[e-mail]>]

> On 2021-02-07, at 05:37, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Carsten Bormann <[e-mail]> wrote:
>> Nice and sweet (although I liked the sequence in -00 of describing
>> current IP before legacy 32-bit IP better).
> 
> I put current IP (v6) first, and v4 second.
> I don't think that changed.

It did, but in the right direction…
Sorry, misread the diff.
>> There needs to be some text about padding in the prefix byte strings.
>> (Ultimately, a prefix is a bit string, which we decided NOT to have as
>> a basic type in RFC 7049; that would be two bytes shorter if we want
>> that.)
> 
> You mean, if I have 2001:db8:1234::/33  ?  That I need to emit 7 bits of
> zeroes, ideally, and/or that the recipient needs to force those bits to 0.

Leaving these bits open as a side channel would actually give you something to write about in the Security considerations?
The padding bits should be sender MUST be zero, receiver MUST check.
And it probably would be useful to define the preferred encoding to not have more padding than needed.

>> I don’t think the current security considerations are worth it — this
>> security consideration applies to any self-describing representation.
>> (And inversely, in a signed object you do want to minimize semantic
>> dependencies from context.)
> 
> I don't mind removing it, but having it blank would seem to be lame.

Wouldn’t it be great to, for once, have a protocol-let that has no security considerations?  Oh, you could always say those from RFC 791 (hmm, doesn’t have any) and 8600 apply.

>> I think it would be useful to have some discussion about the
>> pre-existing tags in this space, but that could be done separately
>> (such as in the notable-tags document, for which I need to find time to
>> update it…).
> 
> An appendix that describes previous work maybe?

Works for me.

How useful is it going to be to be able to drop trailing zero bytes?
My intuition is that this creates busywork for the receiver and almost never can be used anyway.

Oh, and the other thing that is missing is a format for transport addresses (i.e., add a port).

Thanks for picking up this subject!

Grüße, Carsten