Subject: [Model-t] draft-thomson-tmi

From: "Martin Thomson" <[email-masked]>
Date: Mon, 13 Jul 2020 14:32:40 +1000

There have been a lot of discussions recently about the threat model, but I thought that I would contribute something concrete.

This is an attempt to capture what I believe to be the principles behind some of the more prominent recent protocol design efforts.  In some ways this is a broader take than that in RFC 8558, which was a discussion of transport protocols.  QUIC very much embodies these principles, but I could point to a number of other efforts across the IETF.  The principles I recommend are:

   1.  Prefer designs without intermediaries

   2.  Failing that, control which entities can intermediate the protocol, and

   3.  Limit actions and information that are available to intermediaries

The draft is here: https://datatracker.ietf.org/doc/html/draft-thomson-tmi-00
A live HTML version is here: https://martinthomson.github.io/tmi/draft-thomson-tmi.html
And if you feel motivated to contribute, on GitHub: https://github.com/martinthomson/tmi

This might not be the right venue to discuss something like this, but as this came out of discussions in Singapore, I thought I would share it here.  This is less about the threat model than a specific response to some of the threats we've discussed; to that end, it probably isn't in the charter of this group, but I hope that it informs discussion.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 13 Jul 2020 10:55:18 +0200 (CEST)

> Il 13/07/2020 06:32 Martin Thomson <[email-masked]> ha scritto:
> 
>  

I think that this really depends on who you are and how you see the world. There are people who are more afraid of the endpoints, given how hard it has become to be able to know and choose who you (the applications and devices you use) communicate with - so these people would like to become intermediaries, or install intermediaries, to regain control of their communications. Think of concepts like ad blockers, firewalls or network monitors: designing against intermediaries makes them impossible, and I don't think this is good for the Internet (or for anyone but the online advertising and tracking industry).

I would suggest that any analysis aimed at designing a threat model should start by considering both the threats that may come from intermediaries and the threats that may come from entities that control the endpoints; ideally, you would need to ensure that the end-user is protected as much as possible against abuses by both types of parties.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Jul 2020 06:01:27 -0700

On Mon, Jul 13, 2020 at 1:56 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> > There have been a lot of discussions recently about the threat model,
> but I thought that I would contribute something concrete.
> >
> > This is an attempt to capture what I believe to be the principles behind
> some of the more prominent recent protocol design efforts.  In some ways
> this is a broader take than that in RFC 8558, which was a discussion of
> transport protocols.  QUIC very much embodies these principles, but I could
> point to a number of other efforts across the IETF.  The principles I
> recommend are:
> >
> I think that this really depends on who you are and how you see the world.
> There are people who are more afraid of the endpoints, given how hard it
> has become to be able to know and choose who you (the applications and
> devices you use) communicate with - so these people would like to become
> intermediaries, or install intermediaries, to regain control of their
> communications. Think of concepts like ad blockers,

Ad blocking commonly takes place at the endpoint, where it is far more
effective than at the network layer.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Jul 2020 15:30:29 -0400

#2 has pros and cons.  When one connects to a new public wi-fi, some proxies are often offered to reduce latency.  the choice may be to accept these proxies in order to use the service at all.  So, "control" is an interesting choice of words.  However, it would be really useful to always identify the proxies that are involved. 

Russ

> On Jul 13, 2020, at 12:32 AM, Martin Thomson <[email-masked]> wrote:
> 
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Jul 2020 10:25:15 +1000

On Mon, Jul 13, 2020, at 18:55, Vittorio Bertola wrote:
> I think that this really depends on who you are and how you see the 
> world. There are people who are more afraid of the endpoints, given how 
> hard it has become to be able to know and choose who you (the 
> applications and devices you use) communicate with - so these people 
> would like to become intermediaries, or install intermediaries, to 
> regain control of their communications. 

I did not claim that this was addressing all of the problem.  I agree that not being able to trust endpoints that you bought and are responsible for maintaining is a real problem.  I disagree with the idea that more intermediation is any sort of solution.

On Tue, Jul 14, 2020, at 05:30, Russ Housley wrote:
> #2 has pros and cons.  When one connects to a new public wi-fi, some 
> proxies are often offered to reduce latency.  the choice may be to 
> accept these proxies in order to use the service at all.  So, "control" 
> is an interesting choice of words.  However, it would be really useful 
> to always identify the proxies that are involved. 

The scenario you posit is a common one.  Many employers offer a similar choice: allow me to intermediate your web traffic or find another job.  It's not much of a choice, but not strictly a protocol design choice.  The protocol design decision here is whether to design a protocol to include this intermediation or whether to find another way to accomplish the desired goals.

#2 comes in if you decide to design a protocol that involves this proxy. For instance, you might consider using TLMSP [1] over TLS.  And yeah, "control" was a deliberate choice, but it has interesting implications.

[1] https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 Jul 2020 21:33:27 -0700

> I did not claim that this was addressing all of the problem.  I agree that not being able to trust endpoints that you bought and are responsible for maintaining is a real problem.  I disagree with…

Yes. There is a privacy argument that it is important to be able to
inspect what comes out of the device, in order to shine a big light on
possible privacy abuses. There are also two classes of counter
arguments: first, that weakening the data protection of these devices
plays in the hands of a variety of bad actors; and second, that in the
case of competent device makers, inspecting the traffic won't reveal much.

Take the example of a cloud-backed security camera. Inspecting the
traffic will show that it is sending streams of video images to the
cloud service. That won't be a surprise, because that's exactly what the
device is sold for: send the images to a remote service, so the users
can check the security of their home from their cell phone in the
office. At the same time, just knowing that will not tell you that the
images are harvested to feed a facial recognition database, or that they
are made available to the police. That kind of abuse happens in the back
end. And yes, there are real life examples of door-bell cameras doing
exactly that. And of course we could define the same scenarios for
thermostats, light bulbs and many more.

Asking the device makers for a way to inspect their traffic of such
devices won't give you much, and the back doors required for enabling
that are almost guaranteed to be abused by hackers. What you really want
is some form of control on what happens to your data once they reach the
cloud.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Jul 2020 05:44:18 -0700

On Mon, Jul 13, 2020 at 9:33 PM Christian Huitema <[email-masked]>
wrote:

> possible privacy abuses. There are also two classes of counter arguments:
> first, that weakening the data protection of these devices plays in the
> hands of a variety of bad actors; and second, that in the case of competent
> device makers, inspecting the traffic won't reveal much.
>
> Take the example of a cloud-backed security camera. Inspecting the traffic
> will show that it is sending streams of video images to the cloud service.
> That won't be a surprise, because that's exactly what the device is sold
> for: send the images to a remote service, so the users can check the
> security of their home from their cell phone in the office. At the same
> time, just knowing that will not tell you that the images are harvested to
> feed a facial recognition database, or that they are made available to the
> police. That kind of abuse happens in the back end. And yes, there are real
> life examples of door-bell cameras doing exactly that. And of course we
> could define the same scenarios for thermostats, light bulbs and many more.
>
> devices won't give you much, and the back doors required for enabling that
> are almost guaranteed to be abused by hackers. What you really want is some
> form of control on what happens to your data once they reach the cloud.
>
I agree that that would be good. Another approach is to have the devices be
open source so that one can determine what it is they do, rather than
attempting to reverse engineer it from the traffic.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Jul 2020 07:44:54 -0700

On 7/14/2020 5:44 AM, Eric Rescorla wrote:
>
>
> On Mon, Jul 13, 2020 at 9:33 PM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Yes. There is a privacy argument that it is important to be able
>     to inspect what comes out of the device, in order to shine a big
>     light on possible privacy abuses. There are also two classes of
>     counter arguments: first, that weakening the data protection of
>     these devices plays in the hands of a variety of bad actors; and
>     second, that in the case of competent device makers, inspecting
>     the traffic won't reveal much.
>
>     traffic will show that it is sending streams of video images to
>     the cloud service. That won't be a surprise, because that's
>     exactly what the device is sold for: send the images to a remote
>     service, so the users can check the security of their home from
>     their cell phone in the office. At the same time, just knowing
>     that will not tell you that the images are harvested to feed a
>     facial recognition database, or that they are made available to
>     the police. That kind of abuse happens in the back end. And yes,
>     there are real life examples of door-bell cameras doing exactly
>     that. And of course we could define the same scenarios for
>     Asking the device makers for a way to inspect their traffic of
>     such devices won't give you much, and the back doors required for
>     enabling that are almost guaranteed to be abused by hackers. What
>     you really want is some form of control on what happens to your
>     data once they reach the cloud.
>
> I agree that that would be good. Another approach is to have the
> devices be open source so that one can determine what it is they do,
> rather than attempting to reverse engineer it from the traffic.

Open source the software is indeed a good idea but software these days
is only partly on the device. Take the example of the doorbell camera.
If you open source the software, you will verify that what it does is
sending video streams to the cloud. You will not see that the cloud
itself is forwarding the streams to the police, or doing face
recognition and extracting meta-data to document your social graph. If
the problem is in the cloud, the solution has to address the cloud.

-- Christian Huitema

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 14 Jul 2020 14:40:29 -0400

Section 5 makes me realise that there's a gap in protocol considerations 
related to shutdowns (also that 7754 might need an update). Joe Hall's 
draft has a section that overlaps both: 
https://tools.ietf.org/html/draft-hall-censorship-tech-07#section-3.1.

-M

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 15 Jul 2020 16:11:08 +0200 (CEST)

> Il 14/07/2020 02:25 Martin Thomson <[email-masked]> ha scritto:
> 
>  

Part of the problem of this discussion is that different technical and operational communities have different hammers and so are looking to treat everything as if it were a different kind of nail. I mean, you could easily reverse your consideration and agree that not being able to trust intermediaries that you bought Internet service from is a problem, but disagree that less intermediation is any sort of solution.

Or, to Eric's comment, if you make browsers you will use browser-based ad blocking and that will seem to you the common way of doing it, while if you run DNS resolvers (or raspis with a Pi-hole) you will use DNS-based ad blocking and that will seem to you the common way of doing it. Possibly end-usage statistics reflect the dominance of global platforms over local network operators - I don't know the numbers. 

But in the end, I do not know how to reconcile radically different views on where services should be provided from. This is not a technical disagreement, it is more of an architectural and philosophical one with business and geopolitical implications.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 21 Jul 2020 08:11:36 -0500

I'm interested in this topic, but have no special expertise.

>From my point of view,

On Wed, Jul 15, 2020 at 9:11 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

>
> Part of the problem of this discussion is that different technical and
> operational communities have different hammers and so are looking to treat
> everything as if it were a different kind of nail. I mean, you could easily
> reverse your consideration and agree that not being able to trust
> intermediaries that you bought Internet service from is a problem, but
> disagree that less intermediation is any sort of solution.
>
> Or, to Eric's comment, if you make browsers you will use browser-based ad
> blocking and that will seem to you the common way of doing it, while if you
> run DNS resolvers (or raspis with a Pi-hole) you will use DNS-based ad
> blocking and that will seem to you the common way of doing it. Possibly
> end-usage statistics reflect the dominance of global platforms over local
> network operators - I don't know the numbers.
>
> But in the end, I do not know how to reconcile radically different views
> on where services should be provided from. This is not a technical
> disagreement, it is more of an architectural and philosophical one with
> business and geopolitical implications.
>

seems especially relevant.

Best,

Spencer

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 21 Jul 2020 16:02:56 +0200

Hi Christian,

I agree that the even bigger problem is that the user looses control about its data as soon as the data has left their own network and devices. However, that doesn’t mean it is not important to have some control or at least visibility about what data leaves your network. I would say the opposite is the case. The solution to the problem about how your data is maintained is probably regulatory or could be “just don’t install a cloud-backed camera”. Instead, you could probably use a camera that connects to your own gateway to provide this service. However, in this case I really want to make sure that camera really only connects to my gateway and does not also streams the video to the cloud or the police (not even occasionally). At the same time, I guess I still wouldn’t want to block all traffic entirely because I still want to make updates and such. In the end it’s a matter of trust and I might actually trust an independent third-party more than the various IoT companies.

Mirja

> On 14. Jul 2020, at 16:44, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
>> On Mon, Jul 13, 2020 at 9:33 PM Christian Huitema <[email-masked]> wrote:
>> Yes. There is a privacy argument that it is important to be able to inspect what comes out of the device, in order to shine a big light on possible privacy abuses. There are also two classes of counter arguments: first, that weakening the data protection of these devices plays in the hands of a variety of bad actors; and second, that in the case of competent device makers, inspecting the traffic won't reveal much.
>> 
>> Take the example of a cloud-backed security camera. Inspecting the traffic will show that it is sending streams of video images to the cloud service. That won't be a surprise, because that's exactly what the device is sold for: send the images to a remote service, so the users can check the security of their home from their cell phone in the office. At the same time, just knowing that will not tell you that the images are harvested to feed a facial recognition database, or that they are made available to the police. That kind of abuse happens in the back end. And yes, there are real life examples of door-bell cameras doing exactly that. And of course we could define the same scenarios for thermostats, light bulbs and many more.
>> 
>> Asking the device makers for a way to inspect their traffic of such devices won't give you much, and the back doors required for enabling that are almost                 guaranteed to be abused by hackers. What you really want is some form of control on what happens to your data once they reach the cloud.
>> 
>> I agree that that would be good. Another approach is to have the devices be open source so that one can determine what it is they do, rather than attempting to reverse engineer it from the traffic.
> 
> 
> Open source the software is indeed a good idea but software these days is only partly on the device. Take the example of the doorbell camera. If you open source the software, you will verify that what it does is sending video streams to the cloud. You will not see that the cloud itself is forwarding the streams to the police, or doing face recognition and extracting meta-data to document your social graph. If the problem is in the cloud, the solution has to address the cloud.
> 
> -- Christian Huitema
> 
> -- 
> Model-t mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Jul 2020 17:29:51 +0200

On 2020-07-21, at 16:02, Mirja Kuehlewind <[email-masked]> wrote:
> 
> I agree that the even bigger problem is that the user looses control about its data as soon as the data has left their own network and devices. However, that doesn’t mean it is not important to have some control or at least visibility about what data leaves your network. I would say the opposite is the case. The solution to the problem about how your data is maintained is probably regulatory 

Yes.  The interesting question here is what kind of protocol support is needed to support a regulatory framework.  Доверяй, но проверяй.

For instance, I would like to be sure that the data my electricity meter is sending to my electricity broker is what it is supposed to be, and not anything else, whether for criminal intent or gross negligence.  I can just trust my electricity broker and the electricity meter, and I have to trust the broker anyway once they have their hands on the data.  But with respect to what data is leaving my house, it would be better if I had some visibility.

> or could be “just don’t install a cloud-backed camera”. Instead, you could probably use a camera that connects to your own gateway to provide this service. However, in this case I really want to make sure that camera really only connects to my gateway and does not also streams the video to the cloud or the police (not even occasionally). At the same time, I guess I still wouldn’t want to block all traffic entirely because I still want to make updates and such. In the end it’s a matter of trust and I might actually trust an independent third-party more than the various IoT companies.

Any reasonable model needs to be able to enable доверяй, но проверяй.

Grüße, Carsten

---

From: Watson Ladd <[email-masked]>
Date: Tue, 21 Jul 2020 20:01:13 -0400

> Any reasonable model needs to be able to enable доверяй, но проверяй.

If by reasonable you mean requiring one of several extremely
complicated tricks to ensure data can be inspected without revealing
it in plaintext, then this is "reasonable".  Preventing subliminal
channels is extraordinarily difficult.

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 21 Jul 2020 18:13:53 -0700

> channels is extraordinarily difficult.

Recently, I had a discussion with Paul Vixie about the "LeakyPick" tool
(https://arxiv.org/pdf/2007.00500.pdf). Researchers at TU Darmstadt,
INRIA and North Carolina State develop the tool to audit Internet
connected microphones like Alexa and its competitors. The tool would
play prerecorded sentences in front of the microphone, and see whether
the device picked a word as a keyword. They would verify that by looking
at the encrypted traffic coming out of the device. If the device did not
pick the keyword, it would not send any data, but if it did there would
be a burst of traffic. Encrypted traffic of course, but the activity
could still be detected.

Paul's point was that yes, this could be detected now, but there is no
guarantee that it could be detected tomorrow. If they know they are
being watched, device developers could start adding counter-measures,
like cover traffic. Indeed, doing just that became standard for audio
conferences after attacks where published that detected silence-voice
transitions or length of phonemes in the encrypted traffic. Now, voice
codec just send at a constant bit rate, independent of the variations in
speech. The point is that we may have ways to inspect traffic today, but
that does not guarantee we will be able to keep doing that tomorrow.

Unless of course there is a clear requirement that devices can be
audited -- and we need regulations for that.

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 22 Jul 2020 22:35:08 +1000

On Wed, Jul 22, 2020, at 11:13, Christian Huitema wrote:
> Now, voice 
> codec just send at a constant bit rate, independent of the variations 
> in speech. 

I don't believe that this is true.  I don't think that countermeasures against these attacks are very widely implemented.  There is definite leakage, particularly for things like IVRs, so that might be worrying.  Of course, my information is a little dated.

> audited -- and we need regulations for that.

That seems to be the only real solution here.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2020 15:15:52 +0200

On 2020-07-22, at 03:13, Christian Huitema <[email-masked]> wrote:
> 
> Now, voice codec just send at a constant bit rate, independent of the variations in speech. 

Actually, there is a body of literature about extracting information, such as the language being used or even the content of the speech itself, from encrypted variable-bitrate codecs such as those used in CDMA.

E.g., https://dl.acm.org/doi/10.1145/1880022.1880029

Grüße, Carsten

---

From: Colin Perkins <[email-masked]>
Date: Wed, 22 Jul 2020 14:45:39 +0100

> On 22 Jul 2020, at 14:15, Carsten Bormann <[email-masked]> wrote:

Also https://tools.ietf.org/html/rfc6562 <https://tools.ietf.org/html/rfc6562> ("Guidelines for the Use of Variable Bit Rate Audio with Secure RTP”) which warns about this issue.

-- 
Colin Perkins
https://csperkins.org/

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 Jul 2020 08:10:13 -0700

> That seems to be the only real solution here.

Yes. I see the other messages from Colin and Carsten pointing out that
the audio leakage issue is not always fixed in encrypted voice, despite
being well known. I stand corrected and my trust in VoIP services is
notched down one point lower still, but the general point stands. The
general point is that a lot of the device inspection work going on today
amounts to exploiting bugs in the devices. Bugs in the PKI
implementation allow research to conduct MITM attacks and inspect the
traffic, absence of masking traffic or constant length padding allow for
detection of voice activity. There are obviously many bugs in at least
some devices, which can be used in practice for some inspection. But I
don't believe we can rely on that forever. If privacy researchers can
exploit the bugs, so can a variety of hackers. We would rather get the
bugs fixed. But then, we do need a requirement to allow inspection.

My other point is that the most egregious leakage happens in the cloud.
Yes, like Mirja suggests, I would personally not install cloud backed
devices in my house. But that's a trade-off between function and safety,
and today I don't believe we can impose that trade-off to the public at
large. That mean that if there is to be regulation of devices, it has to
address the cloud as well.

-- Christian Huitema

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jul 2020 19:01:34 +0300

Thanks for writing this, Martin.

I largely agree with was written, however, I do have a number of suggestions.

First off, the draft uses some examples from low-in-the-stack intermediaries, many of which aren’t as relevant today as they were earlier. It would be interesting to consider email services (that don’t support good e2e keying, and at the same time benefit from the analysis of the emails for commercial surveillance), DNS resolvers, and other similar cases with more current relevance.

I think Section 2 and the definition of intermediation needs work. Where do we draw the line between functions pass communications from A to B, vs. functions that are used in some form in the communications between A and B? Lets say a translation or discovery service. In either case function may learn things that are private to the communicating parties, it may impact the ability of the communicating parties extend whatever they are doing with new functionality, and so on. Are these intermediaries in the sense of the draft, or not? And why?

Thirdly, I think there’s an issue in the following:

   Many problems caused by intermediation are the result of
   intermediaries that are introduced without the involvement of
   protocol endpoints.

This conflates the role of protocol endpoint and the role of users, equipment owners, etc. A lot of today’s problems are caused by issues where some piece of service or software or equipment does something that isn’t aligned with my interests as the user. For instance, just because the video camera device is an endpoint and willingly sends a stream to the police doesn’t meant that it’s ok from the user’s perspective. There’s obviously an additional potential misalignment between different endpoints, and applications vs. middlemen, but we shouldn’t lose sight of the alignment of the between the user and what ever goes in the app/network/service.

Jari