Re: [Lwip] [T2TRG] QUIC on IoT boards

[Eliot Lear <[e-mail]>]

Hi Василий


> On 20 Jan 2020, at 15:09, Василий Долматов <[e-mail]> wrote:
> 
> 
> absence of encryption can cause that sudden «green signal» be created by joking school pupils.

Absence of authentication and integrity causes that, not encryption.  And that is the distinction that I think we need to draw.  To Dave’s point:

> It would be helpful to distinguish auditing from surveillance. It’s ok for auditing to require the cooperation of the audited entities. That cooperation could, for example, involve the controlled sharing of keys. Eliot does raise a good point, in that auditing may be very hard if keys and cypher suites with PFS are chosen.


Indeed.  The example I gave isn’t really mine.  Some folks at another company who actually build trains and signal systems expressed this precise example to me.  Encryption isn’t inherently bad in this environment, but as you point out there needs to be scalable means to  manage not just auditing, but real time anomaly detection.  Both of these happen today.

There are other examples.

My friend just got a CPAP machine that reports his breathing via a 3g interface, and gives doctors (or anyone else who can hack in) the ability to (a) determine whether my friend is at home and asleep, (b) whether he is breathing properly, and (c) to remotely adjust controls of the machine.

Now… I don’t know the precise makeup of the software running on that machine, but I can tell you a few things:

I definitely want the communications between that device and the doctor’s control system encrypted.
I want that device to have up-to-date software when vulnerabilities are found.
I don’t want that device talking to anyone other than the doctor’s control system.
I only want that device speaking protocols it was designed to speak.

It’s that last one that has me worried from a long term perspective with QUIC.  If the stack hides means to determine directionality, as it does, and applications, as it does, we should take a pause to determine how we would detect whether it has services running on it that aren’t intended, as has happened all too often.[1]. These are use cases that QUIC was not designed to address.

On the other hand, we do want the IoT community to leverage the best that the Web community has delivered, if and when it is appropriate, and even when the whole package is not, it is best that they adopt the components that are, so that they don’t end up having to repeat old mistakes.

Eliot
[1] https://seclists.org/fulldisclosure/2017/Mar/63