[Sis-dtn] [EXT] Deterministic CBOR encoding
Birrane, Edward J.
Edward.Birrane at jhuapl.edu
Thu Nov 18 15:32:48 UTC 2021
Felix,
Section 4 (Canonical Forms) of the BPSec draft (bpsec-27) explicitly
requires Deterministically Encoded CBOR and zeroing reserved/unassigned bits
as part of canonical forms. However, BPSec does allow specific security
contexts to override/require their own canonicalization algorithms if that
is something a context needs to do.
BPSec security blocks themselves are required to use the same encodings as
used when creating a canonical form (e.g., deterministically encoded cbor)
as described in the second paragraph of section 3.6:
"The fields of the ASB SHALL be as follows, listed in the order in which
they must appear. The encoding of these fields MUST be in accordance with
the canonical forms provided in Section 4
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#section-4> ."
-Ed
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272
From: Felix.Flentge at esa.int <Felix.Flentge at esa.int>
Sent: Thursday, November 18, 2021 10:17 AM
To: Birrane, Edward J. <Edward.Birrane at jhuapl.edu>
Cc: kfall+rcs at kfall.com; sburleig.sb at gmail.com; sis-dtn at mailman.ccsds.org
Subject: RE: [EXT] [Sis-dtn] Deterministic CBOR encoding
Cool,
do we currently have any indefinite-length items in BPv7 / BPSEC besides the
bundle itself? Maybe this exception is not needed,
(I have been planning to use indefinite-length arrays in the compressed
reporting block as it could be more efficient in terms of size but I would
be happy to go to definite-length).
Regards,
Felix
From: "Birrane, Edward J." <Edward.Birrane at jhuapl.edu
<mailto:Edward.Birrane at jhuapl.edu> >
To: "Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> "
<Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >,
"sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> "
<sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >
Cc: "sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> "
<sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> >,
"kfall+rcs at kfall.com <mailto:kfall+rcs at kfall.com> "
<kfall+rcs at kfall.com <mailto:kfall+rcs at kfall.com> >
Date: 18/11/2021 15:18
Subject: RE: [EXT] [Sis-dtn] Deterministic CBOR encoding
_____
Felix,
I had almost this exact conversation with Scott Burleigh and Kevin Fall
yesterday.
The approach to addressing this is to clarify what is meant by Canonical
CBOR as part of AUTH48, with a statement of something like the following:
"the CBOR representations of the values of all fields in all blocks must
conform to the Core Deterministic Encoding Requirements as specified in
[RFC8949] except that indefinite-length items are not prohibited."
The intent of the BPv7 spec is clearly to allow some indefinite length
items, as the spec uses indefinite-length items, and the wording in Section
4.1 is meant to describe the encoding of fields within block otherwise. The
exact wording will be figured out once we have the RFC-editor version of the
text to review.
-Ed
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org
<mailto:sis-dtn-bounces at mailman.ccsds.org> > On Behalf Of
Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int>
Sent: Thursday, November 18, 2021 7:02 AM
To: sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org>
Subject: [EXT] [Sis-dtn] Deterministic CBOR encoding
Dear All,
I have spend some time this morning to understand the requirements we get
for the BPv7 CBOR encoding from draft-ietf-dtn-bpbis-31.txt, RFC 8949, and
draft-ietf-dtn-bpsec-27 (actually, I have been worried about a potential
issue with the current BPv7 spec; now I think it is probably ok). Anyway,
this is my understanding of the current situation. Please let me know
whether you share it or not.
draft-ietf-dtn-bpbis-31.txt:
We have:
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4>
4. Bundle Format
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-31#section-4.1>
4.1. Bundle Structure
The format of bundles SHALL conform to the Concise Binary Object
Representation (CBOR [ <https://datatracker.ietf.org/doc/html/rfc8949>
RFC8949]).
Cryptographic verification of a block is possible only if the
sequence of octets on which the verifying node computes its hash -
the canonicalized representation of the block - is identical to the
sequence of octets on which the hash declared for that block was
computed. To ensure that blocks are always in canonical
representation when they are transmitted and received, the CBOR
representations of the values of all fields in all blocks must
conform to the rules for Canonical CBOR as specified in [
<https://datatracker.ietf.org/doc/html/rfc8949> RFC8949].
There are two small issues here:
- Only the first statement is a real requirement for BPv7, the 'must' in the
last sentence is not capitalised meaning it is not normative (AFAIK).
- RFC8949 does not really specify 'Canonical CBOR':
Section 4.2.3 contains the following note:
| Although [
<https://datatracker.ietf.org/doc/html/rfc7049#section-3> RFC7049] used the
term "Canonical CBOR" for its form
| of requirements on deterministic encoding, this document avoids
| this term because "canonicalization" is often associated with
| specific uses of deterministic encoding only. The terms are
| essentially interchangeable, however, and the set of core
| requirements in this document could also be called "Canonical
| CBOR", while the length-first-ordered version of that could be
| called "Old Canonical CBOR".
and G.3:
For a single value in the data model, CBOR often provides multiple
encoding options. A new section (
<https://datatracker.ietf.org/doc/html/rfc8949#section-4> Section 4)
introduces the term
"preferred serialization" (
<https://datatracker.ietf.org/doc/html/rfc8949#section-4.1> Section 4.1) and
defines it for various
kinds of data items. On the basis of this terminology, the section
then discusses how a CBOR-based protocol can define "deterministic
encoding" ( <https://datatracker.ietf.org/doc/html/rfc8949#section-4.2>
Section 4.2), which avoids terms "canonical" and
"canonicalization" from
<https://datatracker.ietf.org/doc/html/rfc7049#section-3> RFC 7049. The
suggestion of "Core
Deterministic Encoding Requirements" (
<https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.1> Section 4.2.1)
enables generic
support for such protocol-defined encoding requirements. This
document further eases the implementation of deterministic encoding
by simplifying the map ordering suggested in
<https://datatracker.ietf.org/doc/html/rfc7049#section-3> RFC 7049 to a
simple
lexicographic ordering of encoded keys. A description of the older
suggestion is kept as an alternative, now termed "length-first map
key ordering" (
<https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.3> Section
4.2.3).
Anyway, for our purposes we probably can understand 'rules for Canonical
CBOR' as the Core Deterministic Requirements in Section 4.2.1 (at least as
long as we don't use maps, see 4.2.3). This view would be supported by
draft-ietf-dtn-bpsec-27:
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#section-4>
4. Canonical Forms
[...]
The canonical form of the primary block is as specified in
[
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#ref-I-D.ietf-
dtn-bpbis> I-D.ietf-dtn-bpbis] with the following constraint.
o CBOR values from the primary block MUST be canonicalized using the
rules for Deterministically Encoded CBOR, as specified in
[ <https://datatracker.ietf.org/doc/html/rfc8949> RFC8949].
All non-primary blocks share the same block structure and are
canonicalized as specified in [
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-27#ref-I-D.ietf-
dtn-bpbis> I-D.ietf-dtn-bpbis] with the following
constraints.
o CBOR values from the non-primary block MUST be canonicalized using
the rules for Deterministically Encoded CBOR, as specified in
[ <https://datatracker.ietf.org/doc/html/rfc8949> RFC8949].
(It would be even better if there would be an explicit reference to Section
4.2.1.)
So, for CCSDS the main questions seems to be whether we are happy enough
with the core deterministic requirements in RFC8949, Section 4.2.1,
basically:
* Preferred serialization MUST be used. In particular, this means
that arguments (see
<https://datatracker.ietf.org/doc/html/rfc8949#section-3> Section 3) for
integers, lengths in major
types 2 through 5, and tags MUST be as short as possible, for
instance:
[...]
* Indefinite-length items MUST NOT appear. They can be encoded as
definite-length items instead.
* The keys in every map MUST be sorted in the bytewise lexicographic
order of their deterministic encodings. [...]
We are not using maps (currently; and may want to avoid in the future) and
shall not use indefinite-length items in (extension) blocks (the whole
indefinite length bundle array should be ok). I would suggest that we
consult with more hardware-oriented people whether the '... as short as
possible ...' requirements would be a problem. If not, I would suggest that
we explicitly require Deterministically Encoded CBOR according to RFC8949,
4.2.1. Otherwise, we might have to define something more CCSDS-specific (and
would risk loosing interoperability with other implementations, in
particular, regarding bundle security).
Regards,
Felix
Disclaimer
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received this e-mail in error, please notify the sender immediately. ESA
applies appropriate organisational measures to protect personal data, in
case of data privacy queries, please contact the ESA Data Protection Officer
( <mailto:dpo at esa.int> dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211118/a2b09916/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6681 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211118/a2b09916/attachment-0001.bin>
More information about the SIS-DTN
mailing list