Subject: [Model-t] Minimization

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 Dec 2021 17:08:39 +1100

draft-arkko-iab-data-minimization-principle-00 is a useful contribution.

As I noted in the other thread, I'm surprised that we routinely have to re-agree that less data is better, but that is where we are.  Publishing a clear statement on this subject would be valuable.

I found the introductory material on this a little indirect.  I would suggest that this concentrate on the application of existing principles to network design.  That is, the principle of least privilege, what you don't know can't hurt you and what they know can't hurt you either", YAGNI (you ain't gonna need it), and that ilk.  A really punchy message is probably better than a lengthy dissertation, so keep this focused.

The principles here seem less well formed as well.

I don't think that you can leap directly to "Transmission is publication".  There is the old adage of "never say anything to a reporter that you wouldn't want in a front-page headline", but I don't think that this attitude is especially helpful.  For the most part, it's just not practical to adopt this posture. 

That is, I'd like to think that there is still a role for people to trust others, despite ample evidence that it might be foolish to do so.

This does touch on some of the important questions we have around the threat models we are starting to build out.  Like with PPM, we're finding ways to provide information with constraints on how it might be used.  For this specific topic however, I would prefer to provide more general advice for designers about how they develop a threat model for their protocol.  That could consider the incentive structures that exist around the treatment of various data elements.

That is a secondary point though and I think it detracts from the draft to spend a lot of time on it.  Same with the idea that anyone might be compromised.  That is not as much a principle for me, but more something that more fully motivates the top-line principle of minimization.

So there is just one headline principle to talk about here: only provide the minim amount of data needed to accomplish your task.

That is, if a service relies on data to function, provide that service with what it needs to know and no more (example: DNS QName minimization).  If you are trading data, know what you are getting in return (and understand how you want to manage the risk of not getting anything back if you are the first one to share) (example: ACME).

Discussion about onward disclosure, terms of use for data, and compromise/breach are all supporting reasons.

Similarly, the part where you control who gets that information is more or less implicit in that.  It's worth being explicit, but it's not the overarching principle.

The draft briefly touches on the incidental, accidental, or unavoidable sharing of information with things like the wire image and more broadly things that traffic analysis might be turned toward.  I think that you want to keep that out of scope, but acknowledge that sometimes information leaks out in ways that is hard to control.  But pulling all of the traffic analysis work into this document would mean that it loses focus, so I would avoid any sort of deep treatment other than to acknowledge that it is a problem for protocol designers and implementers.

That might mean some aggressive cutting of text, but a focused document seems like it would be possible and worth having.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Dec 2021 14:50:07 +0200

Thanks for this, Martin. All good points.

Jari

> On 9. Dec 2021, at 8.08, Martin Thomson <[email-masked]> wrote:
> 
> -- 
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t