Re: [Cbor] Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D & IANA Tag Registration

[Christopher Allen <[e-mail]>]

On Wed, May 31, 2023 at 4:33 PM Wolf McNally <[e-mail]> wrote:

> (4) I think there may be a misunderstanding here. Crypto-agility is a
> non-goal of Gordian Envelope; in fact, we feel that crypto-agility is often
> a huge barrier to understanding and adoption; I think Christopher will have
> more to say about this.
>

To be transparent, Gordian Envelope is specifically designed to have only
one required cryptographic function, a hash algorithm. Every other
cryptographic function happens in layers above Gordian Envelope. If an app
wants to use IETF COSE, W3C Linked Data CBOR, ISO mDOC, or something else,
it can. We very specifically are trying to avoid being a new "security"
protocol and only use a NIST standard hash algorithm (SHA256) and a
well-understood and proven hash tree (patented by Merkle in 1979) for
integrity checking. No new crypto here — only new in that it is designed to
offer integrity checking of graph data in CBOR.

Our main promise, as described in the section on Futureproofing, is that as
> the crypto landscape changes we are sure that we can update the spec to
> incorporate additional cryptographic constructs as they become necessary.
> For now, the only actual normative construct is the hash algorithm:
> SHA-256. This is due to the intractability of handling envelopes (and hence
> hash trees) with hashes created by a multiplicity of algorithms.
>

We investigated if there could be multiple choices (we had originally
chosen the slightly superior Blake3), but having multiple choices causes
too many problems. There were just two many reasons why SHA256 was the
optimum choice today, especially given constrained hardware. We really
don't like how IPFS/Filecoin has 10s of hash algorithms and the
incompatibilities between them and the implementation problems it causes.
I have also written before about my reservations about classic
cryptographic agility at
https://www.blockchaincommons.com/musings/musings-agility/.

The strength and weaknesses of SHA256 are quite well understood, and when
combined in a hash tree, it is even stronger. If there should be a break in
SHA256, we should have plenty of warning, and at that point, we could
register one new tag that is equivalent to our 200 tag, which says "This is
a Gordian envelope, but it uses XXX algorithm". We believe it is premature
to register that next tag or even make decisions now on how to implement
that tag, but if advised to do so, we would as long as the choice of which
next hash algorithm to use is allowed to be "pending", as this topic area
is changing too rapidly.

Nothing in the spec requires that a particular construct for encryption (or
> compression) must be used; it only informatively states what we’re using
> now. As was indicated in the Futureproofing section, we don’t believe that
> we need algorithm specifiers in envelope as the only normative algorithm is
> defined by the spec, and other normative documents will define standards
> for other constructs as well as ways to disambiguate their envelope
> encodings. To be clear: the `encrypted` arm of the envelope is *not* a
> specification for IETF-ChaCha20Poly1305, it is a specification that the
> envelope is *encrypted* by some means and the only requirement is that it
> publishes the hash of the plaintext in a verifiable way: nothing more.
> Likewise the `compressed` arm of the enveloped is *not* a specification for
> DEFLATE, it is a specification that the envelope is *compressed* and that
> it publishes the hash of the uncompressed contents.
>

Our reference implementation (a CLI app) happens to use a conformant IETF
RFC 7539 ChaCha20Poly1305 to demonstrate the `encrypted` option, but it is
not part of the spec. Similarly, we use a conformant IETF RFC 1951 DEFLATE
to demonstrate the `compressed` option, but again, that is not a normalized
part of the spec, purely informative. In both cases, it is the layer above
that makes its own choices. If they want cryptographic agility at that
layer, they can choose one that supports that capability.

-- Christopher Allen