Inline: On Sat, Jun 17, 2023 at 1:42 AM Ilari Liusvaara <[email protected]> wrote:
> On Fri, Jun 16, 2023 at 06:19:01PM -0500, Orie Steele wrote: > > We would like some time to discuss this draft at IETF 117: > > > > https://github.com/ietf-scitt/draft-steele-cose-merkle-tree-proofs > > > https://ietf-scitt.github.io/draft-steele-cose-merkle-tree-proofs/draft-steele-cose-merkle-tree-proofs.html > > > > We've made several changes that were requested at 116. > > > > We provide a sample implementation demonstrating how to use RFC9162 tree > > algorithm with COSE Sign1 to create signed "inclusion" and "consistency" > > proofs. > > > > We updated the draft to support registration of other tree algorithms > which > > can be specified in separate documents. > > > > If there are other changes folks would like to see, we are happy to try > to > > get them in before the cut off date. > > I have hard time understanding what is actually going on, but based on > what I managed to (mis)understand: > > - The "consistency" proofs in RFC9162 are not signed. I can't quickly > evaulate what would be impact of signing those. > > In our draft they are signed, the payload is the "new tree root", and the unprotected header contains the consistency audit path. This allows a verifier to obtain a new proof that proves the previous one they received is still valid, even though the tree / log has grown since then. Signing the root of the consistency proof, gives assurance you are dealing with the same entity that gave you a signed inclusion proof. > The reason why "consistency" proofs are not signed is that those are > just post-hoc auditing methods for showing that no entries have been > dropped from the tree and that history is linear. > > Correct, they prove the append only property... That's a property a transparency service might want to assert in a standard way. RFC9162 defined the minimal structures for both consistency and inclusion proofs for binary merkle trees, but other structures, such as the ones that KT is interested in might need other proof types. I've asked about this in the KT chartering thread, you may be interested in following that discussion: https://mailarchive.ietf.org/arch/msg/keytrans/zyeQZzN1hDTlqIA4e1F8AA5_R1M/ > - There seems to be no context separation between signed "inclusion" and > "consistency" proofs, which is cryptographically suspect. > > Not sure what you mean, since both proof formats can be verified against a known root without digital signatures. The digital signature over attached or detached merkle roots seems to serve a similar function; If the root is recomputed and does not match, the signature fails to verify. A digital signature also provides a better way to secure "log_id" or service provider specific metadata. Do you have a suggestion here? > - If "consistency" proofs are not supposed to be signed, then those > should use their one (tree-algorithm-dependent) structure. > > They do, a consistency proof is: [ tree_size_1, tree_size_2, consistency path] An inclusion proof is: [tree_size, leaf_index, inclusion_path] Neither of these is signed, but the merkle root they produce for a leaf or a previous inclusion proof is... all of this stuff is tree algorithm specific, some tree algorithms might represent consistency and inclusion proofs very differently. > - This seems to rather dramatically reconfigure how signing works and the > inputs, so it should use a new structure. > > I don't think we need a new signature structure in COSE to accomplish this. It was discussed previously and rejected, that is what led to this draft. > - For "inclusion" proofs, maybe something like: > > - root_parameters (bstr-encoded-map). The parameters for root. MUST > contain things like alg and tree_alg (and tree_size)?. > - leaf_parameters (bstr-encoded-map). The parameters for leaf. > - leaf (bstr). The actual leaf data. > - proof (bstr). The inclusion proof. Format depends on tree_alg. > - signature (bstr). Result of signature operation. > - The above requires reconfiguring how signing works. Maybe something > like: > > The leaf context is core canonical serialization of: > > - context: Fixed tstr "merkle-leaf". > - protected (bstr). The leaf_parameters. > - data (bstr). The leaf. > > This is fed as a leaf to the merkle tree algorithm. The resulting > inclusion proof is placed to proof. > > The root context is core canonical serialization of: > > - context: Fixed tstr "merkle-root". > - protected (bstr). The root_parameters. > - root (bstr). The root hash from merkle tree algorithm. > > This is fed to the signature primitive, and the resulting signature is > placed to signature. > > - One usecase of leaf_parameters is dealing with the info leak described > in the document. One can add salt to leaf_parameters to fix it. This > also makes the hash function much stronger. > > I also suspect that various real-world usecases want both per-leaf > and per-tree parameters. > > Indeed, they can create tree algorithms that describe how to combine additional parameters when producing the leaf, or in the protected header. > - I suspect it is necressary to handle redaction of leafs for the > cases where leafs contain material that is just too hot to pushlish > (this can be used as an attack). > > This is not the case, the leaves are hashes, how you retain the original content is out of scope. You can delete the content or a decryption key for it, without removing the leaf from the log. Should this be noted in privacy / security considerations? > At minimum, this means that not having some leaf available (publishing > hash of redacted leaf is okay) must not break auditing of non-removal > and linearity-of-history. > > Interesting... I think this would be a topic for SCITT or KT, since it seems to be a new entry related to older entries. You can imagine treating the append only log, as an event source, and then going full CQRS on it, or redux, or whatever event sourcing pattern you prefer. > - And another thing to talk about is how to deal with log failures. Even > if I don't recall any incident where Certificate Transparency log > failed due to overt malice, I recall several cases where the log > failed due to bugs, and at least two cases where "cosmic ray" caused > the log to fail. > > Interesting : ) but again, probably a better topic for SCITT or KT. Should I mention this in the security considerations section anyway? > This can impact proofs. For example, if there can be multiple > inclusion proofs from various logs, that affects format of "inclusion" > proofs, as one probably does not want to want to repeat leaf in all > the proofs (but leaf_parameters are log-dependent). > > RFC9162 did reference "log_id" several times, I know SCITT needs that property to be secured in the protected header. Detaching the the payload from COSE Sign1 accomplishes this, for example you might have this on your file system: leaf content: publicKey.pem or publicKey.pem.cose (content of a known type, signed with COSE) (leaf: hash, index ... intermediate data) publicKey.signed-inclusion-proof.vendor1.cose (contains intermediate data) publicKey.signed-consistency-proof.vendor1.cose publicKey.signed-inclusion-proof.vendor2.cose (contains intermediate data) publicKey.signed-consistency-proof.vendor2.cose Again a federation, distributed logging problem, better solved for in SCITT or KT... Thank you for your comments! > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
