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

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 <noreply@ietf.org> wrote:
> 
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor