Re: [arch-d] [Model-t] Possible new IAB program on Internet trust model evolution

[Robin Wilton <[e-mail]>]

Thanks, both. As I read your comments, one phrase kept presenting itself to me...
“user agency”. What is it, in the system, that is giving effect to the user’s intention and preferences. I’m not even going to try and guess which layer(s) that thing (or those things) reside, at this point, and I entirely agree that this is an opportunity to take a few deep breaths and consider the problem space.

Best wishes,
Robin
________________________________
From: Eliot Lear <[e-mail]>
Sent: Wednesday, January 29, 2020 9:48:32 AM
To: Bernard Aboba <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Toerless Eckert <[e-mail]>
Subject: Re: [Model-t] [arch-d] Possible new IAB program on Internet trust model evolution

Hi Bernard and thanks for your valuable thoughts.

On 28 Jan 2020, at 23:50, Bernard Aboba <[e-mail]<mailto:[e-mail]>> wrote:

Eliot --

The examples you describe are difficult to capture within protocol-specific threat models (RFC 3552) or privacy considerations (RFC 6973).  For practicality, those analyses need to maintain a narrow focus, yet at the same time we understand that systemic privacy and security issues can only be understood when analyzing the system that a protocol is embedded in.  As a result, even protocols that successfully address the original threat models can be the source of major systemic vulnerabilities. For example, we could not have expected the authors of RFC 1945 (HTTP 1.0) to have anticipated the security and privacy problems arising from today's social media implementations - some of which were discussed during the Internet Privacy Workshop summarized in RFC 6462.

I really cannot say what, if any, protocol changes I would suggest at this point to handle some of the cases I mentioned.  Assuming there is interest in this approach, I would suggest a bit of a collection and a culling.

I want to address one related point: Joel doesn’t think the program should get up into layer 9 too much, and I would say that it would be necessary to do so to figure out where we as a community want to make some Lessiguesque law, and when perhaps we need to leave that to others, but see below.


However, I do think that you're on to something important that is worth IAB consideration.

It strikes me that in a number of the examples you cite the "endpoint" is not acting in the interest of the "end user", at least in the sense described in draft-iab-for-the-users.  As was noted in Section 4.2:


   In contrast, the Internet of Things (IoT) has not yet seen the
   emergence of a natural role for representing the needs of the end
   user.  Perhaps as a result of this, that ecosystem and its users face
   serious challenges.

For example, consider how some of the IoT behavior you describe might be handled within a permission model implemented in a browser or a mobile device:

1. Would a user grant permission to access to camera or microphone?   In the example of the device that did not advertise that it contained a microphone, presumably, the answer would be "no" (although the microphone was not initially enabled so perhaps permission might not have been requested).
2. Would the user grant permission to access personal information such as location?  In the example of the device with embedded trackers, again the user would probably not have granted access to location and other data (although we know that location can easily be obtained in circumvention of browser or mobile device protections).



Very well put.

I think that leads us into a bit of futuristic scenario planning about how that permission model would work, what the control points are, then how they interact, etc.  The L9 discussions come in the form, I think, of incentive modeling to address the for-the-users point.  But that’s for later.  For now, what are the problems?

To Toerless’ point:

Yes, i think we can agree that we would like all Internet end-to-end
transport must not even allow for a misconfigured option to use null
encryption, but i think when TLS 1.3 was standardized, there should have
been a better solution than to completely oppress the needs of those
other use-cases.

And my suggestion is that we take three steps back before we even go there.  Let’s not treat this like an IETF working group, but pause and take deep breaths and work the problem space just a bit.

Eliot