export_key encrypted blobs stored on the server come with liabilities

[stef]

The client output of this stage is a single value export_key that the client may use for application-specific purposes, e.g., as a symmetric key used to encrypt additional information for storage on the server.

this is a dangerous feature, as a malicious user can use this to store plaintext data (for example incriminating CSAM) on the server, and in jurisdictions like germany this can lead to criminal conviction of the unassuming operator of the server. a server has no way of (except for estimating entropy) checking if the data stored is indeed encrypted in any way (may or may not be using export_key). furthermore this can also be used to distribute other illegal content like piracy, command and control infrastructure for malware, etc (if the encrypted data is provided by the server at the createcredentialresponse step). One way to make mitigate against this feature being abused as a public data distribution mechanism, the export_key "encrypted-or-not" blob should be only dispensed after the client successfully authenticated themselves to the server.

maybe this or something similar should be added to the security considerations?

[kevinlewi]

@stef Sorry for the delays in replying! The clause "e.g., as a symmetric key used to encrypt additional information for storage on the server." is meant to be an example on what "application-specific purposes" the export key can be used for.

It certainly isn't meant to be a recommendation that exhaustively considers all of the security implications of doing so. As you point out, there should probably be other mechanisms to authenticate what the client stores on the server using this manner. However, this is outside of the scope of the exposition here, and I don't think merits expanding on in the security considerations. Really, the protocol recommendations end once the export_key is produced, and we are not trying to say how this export key should be used for a secure application.

Together with the fact that we are nearing the end of the draft review process (and not wanting to kick back up more discussion that isn't essential), I'm inclined to not make changes to the security considerations text at this point. Hope that works for you!

[stef]

as you seem to be closing other issues of mine as well, i will write a blogpost with all the open questions that are out of scope or delaying the finalization of the doc. people can then find this additional commentary (pointing also back at these issues and your answer) as additional context. indeed i think (most if not all of) the issues associated with this doc, are incredibly useful for understanding decisions and other aspects that are not covered in the doc itself. as such if nothing else i would insist of a reference in the doc itself to the all the issues in this repository. hope that works for you.

[kevinlewi]

Hi @stef, sounds good to me! This github repo will be added as a link to the "Additional Resources" section of the data tracker website for the document. That will hopefully be a way for others to track down these discussions from the official website.

[kevinlewi]

A link to this github repository has been added to https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/ . Closing this issue.