Subject: [Model-t] minimization review

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Apr 2022 12:00:16 +1000

Hi Jari,

I really like the essential simplicity of the idea behind this draft.  It's a little odd that we find ourselves in need of a statement like this, but - as far as I'm aware - this hasn't been stated so directly before.  So I'm supportive of publishing like this.

This version is definitely more focused than the last, which is an overall improvement.  I've a few comments, that I'll try to keep high-level.

. Comparison with communications security

Your comparison with communications security doesn't quite work for me.  It seems like the key distinction here is that communications security concerns itself primarily with limiting who can access information, where this is talking about limiting the amount of information.  That is, we're talking about the distinction between breadth (how far information is distributed) and depth (how much is distributed).

. Discussion points

Section 3.1 of the draft seems a little confused to me.  When you talk about Oblivious DNS, PPM, encryption at rest, end-to-end protections, and similar (these need citations), I don't think we're talking about minimization as much as we are back to communications security.  That is, this section seems to once again address the "who" part as opposed to the "how much" part.

A strong reason to prefer minimization approaches is that the scope of an exposure/leak/breach is limited.  This is, I think, the central thesis here.  That is, even where an entity might be trusted with data, mistakes and attacks happen. In that case, information that was never provided cannot be revealed.

To that end, this section could be much shorter and more direct.

If you want to draw on those examples, then you might talk about how a system might be designed to avoid having data exposed to any single entity.  That's a much more interesting statement for protocol designers.  But I'm not sure how much you want to draw on that thread as it leads to a fairly lengthy discussion of different design trade-offs, the role of metadata, and related things.  For example, we managed to design Web Push (RFC 8030) to avoid the need for data to be exposed to the intermediary, but the trade there was in metadata: the intermediary is likely able to observe who is communicating with whom.

. Related work

In Section 3.2 I don't think that the first paragraph of "stuff we talked about" is particularly useful if you want to ensure that the document is focused.  And as much as I like the reference to my work, it probably doesn't really advance your central thesis particularly well (the earlier reference might suffice).

I would combine the two path signals documents, or focus mainly on the newer one.  The original RFC 8558 is really talking about the commsec approach of limiting who gets information, but the new one really starts to dig into understanding the shape of the information that is provided.  That's a much stronger reference.

The work on wire image is one I'm less clear on.  If anything, that suggests a security considerations section for the document.  Along with the website fingerprinting reference, recognizing that information might leak inadvertently despite attempts to withhold it is an important point to include.  Data tends to be interconnected and correlated and so saying one thing can often allow for inferences about other things, just like the use of the spin bit in QUIC can reveal that you are behind a NAT or VPN.

Talking about this allows you to make an important point: minimization is not always successful.  For instance, in our work on minimization in geolocation (see RFC 6772) we discovered that the information you think you reveal and the information a determined adversary might be able to learn can be very different.  This topic area gets interesting - either in the "may you live in interesting times" sense or the "you can build an academic career on this" sense, I don't know which - so you probably don't want to say much more than other than include a carefully worded warning.

I hope this helps.  I'm supportive of the IAB saying something concrete here.  Even if it seems like it is obvious, sometimes the obvious needs to be said for it to be recognized.

Cheers,
Martin

---

From: Jari Arkko <[email-masked]>
Date: Tue, 5 Apr 2022 22:40:42 +0300

> Your comparison with communications security doesn't quite work for me.  It seems like the key distinction here is that communications security concerns itself primarily with limiting who can acces…

Are you referring to the second-to-last paragraph of Section 2? If so, I agree that the text definitely needs work.

(But I think the questions about who and how much may not be clearly separate in all cases. We do tell networks some things on purpose, e.g., destination addresses of a packet and use encryption to hide other things. Similar issues can be at play when interacting with a primary protocol participant such as a server. We do tell them too some things on purpose, e.g., the identity of an intended recipient of a message, and should use encryption to hide other things. But even the things we tell the server are encrypted and not disclosed to networks along the path, because they didn’t need to know that. In all of these cases we need to pay attention to what information we give out to a party, and make that match the function we expect the party to do and the trust we have on it.)

> A strong reason to prefer minimization approaches is that the scope of an exposure/leak/breach is limited.  This is, I think, the central thesis here.  That is, even where an entity might be truste…

Yep.

> To that end, this section could be much shorter and more direct.

I agree. There seems to be a distinction in my mind with some things talked about here, e.g., forward secrecy is more about communications security whereas I think some of the oblivious approaches are both about communications security _and_ making sure you tell tell limited information to parties (by splitting information to different parties for instance).

> If you want to draw on those examples, then you might talk about how a system might be designed to avoid having data exposed to any single entity.  That's a much more interesting statement for prot…

Ok. I will read up on that…

> In Section 3.2 I don't think that the first paragraph of "stuff we talked about" is particularly useful if you want to ensure that the document is focused.  And as much as I like the reference to m…

ok.

> I would combine the two path signals documents, or focus mainly on the newer one.  The original RFC 8558 is really talking about the commsec approach of limiting who gets information, but the new o…

ok.

> The work on wire image is one I'm less clear on.  If anything, that suggests a security considerations section for the document.  Along with the website fingerprinting reference, recognizing that i…

ok.

> Talking about this allows you to make an important point: minimization is not always successful.  For instance, in our work on minimization in geolocation (see RFC 6772) we discovered that the info…

Ok, that’s very interesting and I will read up on that as well.

> I hope this helps.  I'm supportive of the IAB saying something concrete here.  Even if it seems like it is obvious, sometimes the obvious needs to be said for it to be recognized.

Thanks,

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 5 Apr 2022 22:43:01 +0300

Yep.

ok.

ok.

ok.

Thanks,

Jari

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Apr 2022 16:10:05 +1000

On Wed, Apr 6, 2022, at 05:40, Jari Arkko wrote:
> Are you referring to the second-to-last paragraph of Section 2? If so, 
> I agree that the text definitely needs work.

This one: https://www.ietf.org/archive/id/draft-arkko-iab-data-minimization-principle-01.html#section-2-4

Which starts: "This recommendation is of course very similar to the current approach to communications security."

> (But I think the questions about who and how much may not be clearly 
> separate in all cases. 

Fair point, it's all minimization.  But the new input here is that it is not sufficient to control breadth, it is also necessary to control depth.