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

[Christian Huitema <[e-mail]>]

On 7/21/2020 5:01 PM, Watson Ladd wrote:

> On Tue, Jul 21, 2020 at 11:30 AM Carsten Bormann <[e-mail]> wrote:
>> On 2020-07-21, at 16:02, Mirja Kuehlewind <[e-mail]> 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 доверяй, но проверяй.
> 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.

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