Re: [icnrg] Vessel Container Format

["David R. Oran" <[e-mail]>]

On 10 Nov 2022, at 4:14, Jens Finkhaeuser wrote:

> Hi,
>
> after my presentation on Tuesday, one question was raised that I feel I did not respond to satisfactorily, which I would like to address now: why focus on deletion so much?
>
> There are two answers.
>
> 1.  It's the law. I am not a lawyer, of course, so the actual legal interpretation of such things remains to be seen. But I would doubt that when faced with someone legally requesting the deletion of PII, a judge would look kindly upon an answer that is effectively "I forgot I have it". The exact measure of "reasonable effort" is not up to me, but I think a slightly better answer than that is going to be required if such a thing is tested (I recall similar arguments surrounding the notion of legally copying IP-protected data).

It’s in my view a fools errand to make a protocol design / architecture way more complicated and less resilient to pursue a property like deterministic deletion that cannot in practice be achieved.

The law on this will eventually catch up, as it has in other similar areas, like how “fair use” restrictions used to prohibit caching of copyrighted video (in Germany), and forced “cloud DVR” systems to keep a physical copy of recorded content per-user and not de-duplicate (in the U.S.).

The actual legal property that’s needed is to ensure that no system holding the physical bits also holds the decryption keys. This is quite hard, of course, but at least not completely infeasible as would be tracking down and blasting all the copies of the bits using secure erase (so they can’t be recovered from discarded media).

> 2.  Relying on cryptography assumes everything working well, until the cryptographic solution fails, at which point all bets are off.

That’s right. All bets are off if the cryptographic system fails. Not just deletion but many many things that are a lot more damaging. Of all the things to depend on, crypto is probably the least likely to have catastrophic failures. The failures we’ve seen have been primarily in the implementations, particularly of the key management. What leads anyone to believe that the implementations of deletion by secure erase would be any less susceptible to error?

> But there are plenty on scenarios that are not that binary. Specifically, it is not guaranteed that a malicious party that comes into possession of a compromised key does so after already having received encrypted content blocks. In such a scenario, of course, deletion does nothing.
Correct.

>     But in a more opportunistic scenario where the malicious party requests content only as a result of having acquired a key, deletion can protect against leaking of sensitive data. Such mitigation also relies on a specific sequence of events (deletion to occur before requesting), but this sequence is far from improbable.
If you can throw away the content, why can’t you throw away the key?
While the fundamental problem is recursive (the keys are themselves data that needs to be deleted) dealing with keys is in many ways easier:
- many fewer bits
- held in secure enclaves that unless compromised by implementation errors, can expire keys in a timely fashion and require that they be refreshed.
- depending on keys protects better against zombie failure modes where some cache or other repository goes offline for a long time (e.g. longer than the key lifetimes) and then comes back online way after the state you kept to enforce deletion has been itself thrown away.

(Funny historical reference: on the 20 or 30th anniversary of the ITS timesharing system - I forget which - somebody booted up an old backup and emails that were in the send queue when it was shut down went out!).

-
>
>
> In summary, I consider it somewhat negligent not to include deletion as a first class problem into ICN solutions, but YMMV of course.
I respectfully disagree. I do not think that rapid enough content deletion is in practice achievable and adds a non-trivial amount of complexity to the system which increases the probability of other more serious failure modes.

>
> At any rate, thank you very much for this feedback! At minimum, it's become clear that I need to stress these points in the draft.
>
> Jens

> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg
DaveO