Re: [Cbor] draft-ietf-cbor-network-addresses: tag validity; deterministic encoding

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 08 October 2021 22:40 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 4243E3A0C35 for <cbor@ietfa.amsl.com>; Fri, 8 Oct 2021 15:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UgWkJ50Xu8FV for <cbor@ietfa.amsl.com>; Fri, 8 Oct 2021 15:40:46 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B451B3A0C2A for <cbor@ietf.org>; Fri, 8 Oct 2021 15:40:42 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id d13-20020a17090ad3cd00b0019e746f7bd4so10377217pjw.0 for <cbor@ietf.org>; Fri, 08 Oct 2021 15:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1RUAp0pIP8IoX/FPcmvTU3XZsk8NAxa1lxdinbtBP5o=; b=ojl1Nxdzqmrio6tQ6ahRNTTH+b/bD293VqQLUx/bkoIs6M5TUP9BCC80J97/x8CHdn DfEqYdOjsAz+4SjLQndd77uchfEusV6zsdkRsxlobUAqx1Pxx/kZpk6jf3QJukWt576b AxWbLtXK7/P0x/sR7ow3UGSKa1ZiIOAjd+yHGDpXq8sjEFh8WXulT7bOueLMQd/U5gei FnnwGg93/HD/SNVm19Urajtz6JN7AV5Og0iZgPtqmUzrk43D//k3UBfyIhLKGlkY6wJQ HwY/J5sgClSfOUEA5Gpqq6AuFqcuyH8miX72g3jUmqtPeOiVcAmx6ejLuzhfbS2vxB6L NTBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1RUAp0pIP8IoX/FPcmvTU3XZsk8NAxa1lxdinbtBP5o=; b=WIdNQymQmuxNxkPwMhFR5pZBMO4mCYqSjCUU3T6EOIcNqsqrRk53QV302ty3l03ce5 LBPybRPli5r0KQ74IY0D3UDlLJobC8/0Sm5G7SZmbJhsfAQsHF7phUwjUI7Tife2td0+ VZWL2tBiLaXSj4JNrW9nCGOzXW3Mxup2Cjg4ZO7aT1k0vGusZDZHJ9WsDiuLtNdNTZPA 3S1cURL0NfhQr6YphTqwKK+fbDU2AMWxOV86f0BA1x4RnKRk24Vj+6W77/MI188+NSfm D0W7v6D4/GiZuN6tPbh0sOdgPz+BKxuSErfhNGD1QuAxj/ftKG7oSl7TJTkC4TCodxEi gQZg==
X-Gm-Message-State: AOAM532l0X5gatphovcPKSQzpcYsPRARLQdxLw9VozFGRqnv8qTTEyX5 hIj7CsBXOA4NCeEGQYNKqhY=
X-Google-Smtp-Source: ABdhPJxM7qde/0tDWndNFTA+e3IEU4LAPuKX+ENnLPI6edgseNAicIWQR+8QfFj4r0W98jgy01lNhQ==
X-Received: by 2002:a17:90b:3850:: with SMTP id nl16mr14313230pjb.127.1633732841982; Fri, 08 Oct 2021 15:40:41 -0700 (PDT)
Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id o10sm323089pgv.74.2021.10.08.15.40.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 15:40:41 -0700 (PDT)
To: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
References: <891995AA-2854-431E-9242-98FFCDA5E161@tzi.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <dab25fe3-43c4-865e-2c7a-54b24340c295@gmail.com>
Date: Sat, 9 Oct 2021 11:40:36 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <891995AA-2854-431E-9242-98FFCDA5E161@tzi.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/B-IqQj4SVhUWvF6xI3-n4NBNaUs>
Subject: Re: [Cbor] draft-ietf-cbor-network-addresses: tag validity; deterministic encoding
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 22:41:02 -0000

On 09-Oct-21 00:52, Carsten Bormann wrote:
> There are various admonitions scattered in draft-ietf-cbor-network-addresses 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 various observations about those admonitions during IESG 
processing, I went ahead and consolidated the actual content to a proper section about Tag Validity.
> 
> https://github.com/cbor-wg/cbor-network-address/pull/15
> 
> I also wrote:
> 
>> The tag validity rules, combined with the rules in {{Section 4.2.1 of
>> -cbor}}, lead to deterministic encoding for tags 54 and 52 and require
>> no further Additional Deterministic Encoding Considerations as per
>> {{Section 4.2.2 of -cbor}}.
> 
> … which might come in handy when deterministic encoding is actually needed.
> 
> Comments welcome before we merge.

I glanced at my Python code while checking the PR and noticed this:

>> A recommendation for prefix decoder implementations is to first create
>> an array of 16 (or 4) zero bytes.

That's exactly what I don't do in my code, although I'm sure it's exactly
what I would do in C. I think 'recommendation' is a bit strong.

>> check that any unused
>> bits in the byte string are zero:

I came up with this:

    if prefix[length//8] & bytemasks[length%8][0] != prefix[length//8]:
        #extra bits in prefix, signal an error

I also came up with a corner use case - suppose all I want to convey is
a prefix length but no prefix? At the moment, I simply send an all-zeroes
prefix, but those are wasted bits. Probably, this isn't worth fixing.

   Brian


> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>