Mitigate poison datasets in ECDSA when canonicalizing.

[msporny]

This PR implements a new requirement to detect dataset poisoning by default in VC Data Integrity PR w3c/vc-data-integrity#128

---

Preview | Diff

[dlongley]

I agree with Ivan that this isn't needed. I'm not blocking either way, but I think the spec is simpler without it since it's already covered by the dependency.

[pchampin]

Suggested change

	implementations MUST detect <a data-cite="RDF-CANON#dataset-poisoning">
	dataset poisoning</a> by default and abort processing.
	implementations MUST ensure that, by default, <a data-cite="RDF-CANON#dataset-poisoning">
	poison datasets</a> are detected and not processed.

The current wording emphasizes the responsibility of the caller of the RDFC-1.0 algorithm. But in rdf-canon, we encourage implementers of that algorithm to abort when they detect a poison dataset. So most users would only have to check that the RDFC-10 implementation they are using has the appropriate default for them, or set the mitigation parameters. Of course, in some situations, they may need to detect poison graph themselves...

[msporny]

Fixed in 0b489fa.

[msporny]

I agree with Ivan that this isn't needed. I'm not blocking either way, but I think the spec is simpler without it since it's already covered by the dependency.

@OR13 wanted it in the spec and seemed to indicate that he would object if it wasn't in there, so we're putting it in there.

[msporny]

@OR13 wanted it in the spec and seemed to indicate that he would object if it wasn't in there, so we're putting it in there.

*sigh* I didn't see the objections to merging the normative language in w3c/vc-di-eddsa#51 (review)

@OR13 would you continue to object if we did an advisement instead? I agree w/ those objecting to a normative statement that is duplicative of the normative statement in RDF-CANON (but not to the level of objecting to the language given that you've said that you'd object if we don't have normative language).

[OR13]

@msporny I think an advisement is probably better... If you do it as a MUST, then implementations will have to prove that they are not vulnerable to the attack... which seems like a burden for non technical implementers.

[msporny]

@msporny I think an advisement is probably better...

Ok, there is a PR to do that here (which you have approved, so that's what we'll do):

#24

If you do it as a MUST, then implementations will have to prove that they are not vulnerable to the attack... which seems like a burden for non technical implementers.

I expect that we'll have a poison graph attack as one of the tests, which we might be able to justify because of the normative requirement on RDF-CANON that the non-JCS data integrity suites have. The RDF-CANON tests will definitely have a poison graph detection/abort test so as long as underlying implementations use a conforming RDF-CANON processor, they will detect poison graphs. We might want to double-check that at the Data Integrity layer just to be doubly sure that one that isn't conformant w/ that statement doesn't sneak through.