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

Carsten Bormann <cabo@tzi.org> Fri, 08 October 2021 23:05 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AD3A0CBB; Fri, 8 Oct 2021 16:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFvyFNTJVb7U; Fri, 8 Oct 2021 16:05:25 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C193A0CBA; Fri, 8 Oct 2021 16:05:24 -0700 (PDT)
Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (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.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <163357136013.2322.3640274684292396357@ietfa.amsl.com>
Date: Sat, 9 Oct 2021 01:05:19 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-cbor-network-addresses@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A168D53C-9D58-46DE-B7F0-8AB4B23B5EE9@tzi.org>
References: <163357136013.2322.3640274684292396357@ietfa.amsl.com>
To: John Scudder <jgs@juniper.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/eCyrkBwbIXtW7hRTdmMaebXB0Zg>
Subject: Re: [Cbor] John Scudder's Discuss on draft-ietf-cbor-network-addresses-10: (with DISCUSS)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=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

   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