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

Carsten Bormann <> Fri, 08 October 2021 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E5AD3A0CBB; Fri, 8 Oct 2021 16:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KFvyFNTJVb7U; Fri, 8 Oct 2021 16:05:25 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94C193A0CBA; Fri, 8 Oct 2021 16:05:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4HR3gh1Jvhz2xkh; Sat, 9 Oct 2021 01:05:20 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sat, 9 Oct 2021 01:05:19 +0200
Cc: The IESG <>,,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: John Scudder <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Cbor] John Scudder's Discuss on draft-ietf-cbor-network-addresses-10: (with DISCUSS)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Oct 2021 23:05:30 -0000

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

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

Grüße, Carsten

> On 7. Oct 2021, at 03:49, John Scudder via Datatracker <> 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
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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