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

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Feb 2021 03:49:43 +0100

Nice and sweet (although I liked the sequence in -00 of describing current IP before legacy 32-bit IP better).
Need to update the IANA considerations with the new array order.
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.)

We use the term “byte string”, not “bytestring” or “byte-string”.

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 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…).

Grüße, Carsten

> On 2021-02-07, at 03:21, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : CBOR tags for IPv4 and IPv6 addresses and prefixes
>        Author          : Michael Richardson
> 	Filename        : draft-richardson-cbor-network-addresses-01.txt
> 	Pages           : 4
> 	Date            : 2021-02-06
> 
> Abstract:
>   This document describes two CBOR Tags to be used with IPv4 and IPv6
>   addresses and prefixes.
> 
>   RFC-EDITOR-please remove: This work is tracked at
>   https://github.com/mcr/cbor-network-address.git
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-richardson-cbor-network-addresses/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-richardson-cbor-network-addresses-01.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-richardson-cbor-network-addresses-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 23:37:47 -0500

Carsten Bormann <[email-masked]> 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.

    > Need to update the IANA considerations with the new array order.

Yes, I saw that in the diff, it's updated in github now.

    > (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.

    > We use the term “byte string”, not “bytestring” or “byte-string”.

okay.

    > 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.

    > 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?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 7 Feb 2021 05:54:01 +0100

> On 2021-02-07, at 05:37, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

It did, but in the right direction…
Sorry, misread the diff.
> 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 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.

> 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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 07 Feb 2021 03:49:58 -0500

> Leaving these bits open as a side channel would actually give you
    > something to write about in the Security considerations?

Yes, that's a good point as to why they MUST be zero.
I tend to think about what a receiver SHOULD do when it gets bad data.

    > have more padding than needed.

Agreed.

    > How useful is it going to be to be able to drop trailing zero bytes?

If you have a lot of /48s to describe, then it would be a win.
My notation does not let you apply the single tag a group.

Maybe:
    TBD1([[ 48, h'20010db81234'],...])

should be valid too.

    > never can be used anyway.

I disagree.  The receiver has an empty (zeroed) sockaddr6 on in6_addr.
The receiver just memcpy's the number of bytes received.
Somewhere along there, a check for non-multiple of 8 is applied to zero the
trailing bits.

    > addresses (i.e., add a port).

So we'd wind up needing a protocol, scope and port.
I'd say that a "sockaddr" TAG is appropriate here, with the v4/v6-ness
established by these tags.  Or maybe not. ANIMA GRASP has all that stuff.

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 8 Feb 2021 13:16:26 +0100

Hi,

> established by these tags.  Or maybe not. ANIMA GRASP has all that stuff.

Yeah, an address with a port without a protocol has no meaning. It'd
either need to become more like a sockaddr (like a POSIX socket, with a
type and/or protocol) or like a URI up-to-authority-component (ie. an
Origin; a subset of core-href may make sense here).

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom