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

[John Scudder via Datatracker <[e-mail]>]

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.