search

w3c / vc-di-ecdsa

Data Integrity specification for ECDSA using NIST-compliant curves
https://w3c.github.io/vc-di-ecdsa/
Other
9 stars 9 forks source link

Mitigate poison datasets in ECDSA when canonicalizing. #21

Closed msporny closed 10 months ago

msporny commented 11 months ago

This PR implements a new requirement to detect dataset poisoning by default in VC Data Integrity PR https://github.com/w3c/vc-data-integrity/pull/128

Preview | Diff

msporny commented 10 months ago

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 commented 10 months ago

@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 https://github.com/w3c/vc-di-eddsa/pull/51#pullrequestreview-1552213045

@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 commented 10 months ago

@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 commented 10 months ago

@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):

https://github.com/w3c/vc-di-ecdsa/pull/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.