Subject: [Cbor] John Scudder's Discuss on draft-ietf-cbor-network-addresses-10: (with DISCUSS)

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 06 Oct 2021 18:49:20 -0700

John Scudder has entered the following ballot position for
draft-ietf-cbor-network-addresses-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document. In general I found it easy to read, blessedly
concise, and useful. I do have one concern with how you treat the covert
channel concern you raise, which I'm making a DISCUSS (which I think will be
easily cleared).

Section 4 says:

   even though variations like:

   54([44, h'20010db81233'])
   54([45, h'20010db8123f'])

   would be parsed in the exact same way; they MUST be considered
   invalid.

You choose to use a RFC 2119 keyword here, and this is in the encoder section,
so presumably you are insisting that the encoder MUST... what? You already
said, in an earlier paragraph, that the encoder MUST set the trailing bits to
zero, so I can't figure out what the quoted text is telling me to do.
(Presumably any compliant encoder won't produce the depicted values, and an
encoder that's noncompliant for the purpose of deliberately exfiltrating data
using this covert channel won't be put off by this MUST.)

Then in Section 5 we have:

   A particularly paranoid decoder could examine the lower non-relevant
   bits to determine if they are non-zero, and reject the prefix.  This
   would detect non-compliant encoders, or a possible covert channel.

The fairly dismissive tone ("paranoid decoder could"), not to mention the
preceding pseudocode, suggests that you have no real expectation the decoder
will do anything to "consider invalid" values with nonzero low bits. So
probably the MUST from Section 4 isn't meant to apply to the decoder.

In short I don't understand what that clause in Section 4 is telling me to do.
One fix would simply be to weaken the text, as in

   would be parsed in the exact same way, they should not be
   considered legitimate encodings.

P.S.: The semicolon in the quoted text is also either wrong, or I'm even more
confused about what's being specified than I thought I was.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Oct 2021 13:52:05 -0400

> channel concern you raise, which I'm making a DISCUSS (which I think will be

okay.

    > would be parsed in the exact same way; they MUST be considered

okay, the intention is that encoders MUST clear and decoders MUST check.
(I'd rather write SHOULD for decoders)

    > The fairly dismissive tone ("paranoid decoder could"), not to mention

My dismissive tone is because:
  a) the checking code is a new code path and creates new test cases
  b) if there was a covert channel, by the time the decoder see it, it's
     already too late.
  c) it's 1 to 7 bits per prefix, not really a large channel.

OTH, if at least some decoders don't check and reject (if they are tolerant
in what they accept), then encoders don't bother to clear (aren't conservative
in what they send).

    > confused about what's being specified than I thought I was.

I have changed it to say:

+would be parsed in the exact same way, they MUST be considered invalid by decoders.

and also:

-A particularly paranoid decoder could examine the lower non-relevant bits to determine if they are non-zero, and reject the prefix.
+Decoders MUST examine the lower non-relevant bits to determine if they are non-zero, and reject the prefix if they are not.

We have also added IPv4 zone identifiers, and as soon as I've caught up with
that discussion, I'll post -11.

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

---

From: John Scudder <[email-masked]>
Date: Thu, 7 Oct 2021 20:35:37 +0000

Hi Michael,

Some comments in line below.

> On Oct 7, 2021, at 1:52 PM, Michael Richardson <[email-masked]> wrote:
[…snip…]
> +would be parsed in the exact same way, they MUST be considered invalid by decoders.

OK. Maybe even a little better would be the same but append “(see below)” or “(see Section x.y)”? It just makes me twitch that you’re putting a MUST for *decoders* into a section titled “*Encoder* Considerations for Prefixes”. From that point of view the MUST is misplaced in this section and the text could be “… would be parsed in the exact same way, Section x.y. requires they be considered invalid.” 

> +Decoders MUST examine the lower non-relevant bits to determine if they are non-zero, and reject the prefix if they are not.

That definitely makes it more consistent. There remains the contradiction between that requirement, and the requirement right above, to coerce the low bits to zero. There’s no point in coercing them to zero if you MUST reject the prefix, is there?

So, ISTM that you need to either

a) Make the text quoted above a SHOULD instead of a MUST, move the “Finally, looking at the last three bits” text and pseudo-code to follow, and make it say something like “if the decoder chooses not to reject a prefix whose lower non-relevant bits are nonzero, then it MUST force them to zero…” 

b) Or if you keep the “reject the prefix” text as a MUST, then remove the coerce-to-zero text and pseudocode, because it’s the equivalent of a region of code that can’t be reached.

Thanks,

—John

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 9 Oct 2021 01:05:19 +0200

Hi John,

I agree with the gist of your DISCUSS.

Instead of sprinkling various admonitions over the draft about doing the right thing when encoding and decoding the tags, we do have a concept in CBOR to handle this properly:
Tag validity (Section 5.3.2 of RFC8949).

In response to your (and others’) observations about those admonitions, we went ahead and consolidated the actual content to a proper section about Tag Validity.

Since there are quite a few other changes in

   https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-11

…it may be easier to dig out the new section 4 in the original pull request:

   https://github.com/cbor-wg/cbor-network-address/pull/15

Grüße, Carsten

> On 7. Oct 2021, at 03:49, John Scudder via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor