Subject: [T2TRG] QUIC on IoT boards

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jan 2020 10:24:39 +0200

Hi,

I wrote up my experiences of getting QUIC to run on some IoT boards for the NDSS DISS workshop. Feedback welcome!

Towards Securing the Internet of Things with QUIC. Lars Eggert. Proc. NDSS Workshop on Decentralized IoT Systems and Security (DISS), San Diego, CA, USA, February 23, 2020. https://eggert.org/papers/2020-ndss-quic-iot.pdf

Would be happy to chat about this more, possibly in Vancouver?

Thanks,
Lars

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 20 Jan 2020 09:52:01 +0000

Hi Lars,

Excellent stuff, thank you for sharing the data.

It'd be nice to evaluate the QUIC stack against CoAP/DTLS on a sample of the typical interactions, e.g.:
- streaming sensor measurements (device to cloud;  long-lived, more or less sparse)
- firmware updates (cloud to device; bulky)
- device management (bidirectional; typically lightweight)

I'd be happy to help out with the characterisation, as well as the practicalities.

Cheers, thanks!

On 20/01/2020, 08:25, "T2TRG on behalf of Lars Eggert" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thanks,
    Lars

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jan 2020 11:55:48 +0200

Hi,

> - device management (bidirectional; typically lightweight)

yes, lots more effort is needed to analyze different scenarios, and to improve the code. The "future work" section is lengthy for a reason :-)

> I'd be happy to help out with the characterisation, as well as the practicalities.

Thanks for the offer!

One possibility could be to gather interested people during the Vancouver hackathon and chat? I am normally at the QUIC table, but could defect for a few hours...

Lars

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Mon, 20 Jan 2020 13:45:11 +0000

Hi Lars,

A fundamental question to ask is whether which IoT uses QUIC is appropriate for and which ones it is not.  For example, obscuring port information on an industrial device – not to mention encrypting communications – might actually cause more harm than good if the result is an inability to audit industrial automation behavior.  As in: why did that signal turn green that caused two trains to collide?

Be careful what you wish for.  You may not like the results.

Eliot

> On 20 Jan 2020, at 09:24, Lars Eggert <[email-masked]> wrote:
> 
> Signed PGP part
> Hi,
>

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 20 Jan 2020 09:01:30 -0500

On 20 Jan 2020, at 8:45, Eliot Lear (elear) wrote:

> Hi Lars,
>
> A fundamental question to ask is whether which IoT uses QUIC is 
> appropriate for and which ones it is not.  For example, obscuring port 
> information on an industrial device – not to mention encrypting 
> communications – might actually cause more harm than good if the 
> result is an inability to audit industrial automation behavior.  As 
> in: why did that signal turn green that caused two trains to collide?
>
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.

>> I wrote up my experiences of getting QUIC to run on some IoT boards 
>> for the NDSS DISS workshop. Feedback welcome!
>>
>> Towards Securing the Internet of Things with QUIC. Lars Eggert. Proc. 
>> NDSS Workshop on Decentralized IoT Systems and Security (DISS), San 
>> Diego, CA, USA, February 23, 2020. 
>> https://eggert.org/papers/2020-ndss-quic-iot.pdf
>>
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

DaveO

---

From: Василий Долматов <[email-masked]>
Date: Mon, 20 Jan 2020 17:09:51 +0300

> 20 янв. 2020 г., в 16:45, Eliot Lear (elear) <[email-masked]> написал(а):
> 
> Hi Lars,
> 

absence of encryption can cause that sudden «green signal» be created by joking school pupils.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jan 2020 15:52:00 +0100

Hi Василий

> On 20 Jan 2020, at 15:09, Василий Долматов <[email-masked]> wrote:
> 
> 

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jan 2020 17:08:58 +0200

Hi,

On 2020-1-20, at 16:52, Eliot Lear <[email-masked]> wrote:
> 	• 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.

I don't quite follow. Surely if someone ships an IoT device that uses QWUIC for communication, that *is* a device "designed to speak" 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.

So [1] is a case where the firmware web server had an embarrassing bug - it's not an example where someone hacked in and ran another service in addition to (or instead of) the manufacturer one. So that's not a fitting example for the point you are trying to raise.

We can certainly debate whether more encryption and/or obfuscation makes network-based threat detection harder or not. It might even be the case that there are wrinkles in the IoT space that aren't there in the broader web space, in terms of appropriateness or trade-offs. But in general, I think this issue is a general one, and not IoT-specific.

> 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 the…

Exactly. Given the ever increasing amount of engineering cycles that are being poured into QUIC, the IoT community should absolutely try to leverage that to the max, where it can.

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Jan 2020 18:00:25 +0100

Hi Lars,

> On 20 Jan 2020, at 16:08, Lars Eggert <[email-masked]> wrote:
> 
> Hi,
> 
> I don't quite follow. Surely if someone ships an IoT device that uses QUIC for communication, that *is* a device "designed to speak" QUIC?

QUIC is the substrate.  It’s the applications atop that really are at issue.
> So [1] is a case where the firmware web server had an embarrassing bug - it's not an example where someone hacked in and ran another service in addition to (or instead of) the manufacturer one. So…

Yes it is.  It’s a misconfiguration that could easily be blocked with the existing TCP model, and it was in a great many environments.  With QUIC, spotting these sorts of misconfigurations may prove more difficult.  Not impossible, mind you.

> We can certainly debate whether more encryption and/or obfuscation makes network-based threat detection harder or not. It might even be the case that there are wrinkles in the IoT space that aren't…

Let’s agree that IoT is a pretty big category.  I gave you two very specific examples of where TLS 1.3 itself is more of a hindrance than a help because of the nature of the system in play.  Those examples comprise a common case for IoT.  I would never say the same thing about browser based communications.  Because IoT is such a big category, there may be cases where privacy issues either conflict with or will overtake other concerns.

Let me give you a good example of conflict:

Dad wants to know what information daughter’s Internet toy is exfiltrating and to whom.  Does the toy have a camera or a microphone that wasn’t advertised in the documentation, as happened with one particular device[1]?  On the other hand, dad would very much like whatever information is being shared to only be shared with authorized parties.

Want more conflict?  Let’s assume that the CPAP machine I described above uses my local wifi and something goes wrong, and the patient dies.  The next of kin want the data, but the CPAP service owner refuses.  In fact, the CPAP service owner even refuses to describe what data is being collected.  On the other hand, a patient would very much like whatever information is being shared to only be shared with authorized parties (2nd verse, same as the first).

Now… some of this is encryption and some of this is transport, but the QUIC and H3 have intentionally intertwined the two to attempt to reduce middle box interference.  That very interference is what a great many IoT deployments need.

> Exactly. Given the ever increasing amount of engineering cycles that are being poured into QUIC, the IoT community should absolutely try to leverage that to the max, where it can.

But the community also requires guidance to understand where it is appropriate, and quite frankly I don’t think we know that yet.

Eliot

[1] https://edition.cnn.com/2019/02/20/tech/google-nest-microphone-secret/index.html

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 21 Jan 2020 10:07:18 +0000

Hi Eliot,

I find your example rather disturbing. I am sure a dad does not want everyone else on the Internet to see what his daughters toy is exfiltrating. You would need encryption for that?

I am totally with you on the need for knowing what's inside the device and how is the device behaving. RFC 8576 identifies this in Section 5.6 'Verifying Device Behavior': https://tools.ietf.org/html/rfc8576#section-5.6

--Mohit

On 1/20/20 7:00 PM, Eliot Lear wrote:
Hi Lars,

On 20 Jan 2020, at 16:08, Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 2020-1-20, at 16:52, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:
• I only want that device speaking protocols it was designed to speak.

Eliot

_______________________________________________
Lwip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lwip

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jan 2020 11:24:48 +0100

Hi Mohit

> On 21 Jan 2020, at 11:07, Mohit Sethi M <[email-masked]> wrote:
> 
> Hi Eliot,
> 

Yes, you would!  But Dad might want to be able to have an agent to decrypt.  Indeed Dad may want an agent that blocks certain

> 
> I am totally with you on the need for knowing what's inside the device and how is the device behaving. RFC 8576 identifies this in Section 5.6 'Verifying Device Behavior':https://tools.ietf.org/html/rfc8576#section-5.6 <https://tools.ietf.org/html/rfc8576#section-5.6>

Well indeed.  But I do think we should be considering what the first class objects are in these cases.

Eliot

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 21 Jan 2020 08:49:42 -0500

On 21 Jan 2020, at 5:24, Eliot Lear wrote:

> Yes, you would!  But Dad might want to be able to have an agent to decrypt.
Sure, which is why key sharing is probably appropriate and having standards for doing that safely are important. Do we have a good way to maintain PFS in those scenarios?

> Indeed Dad may want an agent that blocks certain
I can see two related reasons why this might be important:

1. To prevent “packet of death” scenarios where either bugs or malware can be exploited by a single crafted packet making it through to a vulnerable device.

2. To mitigate DoS attacks against devices that are not prepared to discard traffic effectively, either due to processing or energy considerations.

#1 is quite difficult to achieve without full middle-box functionality, in which case I’d argue that rather than ACL-like blockage based on things like ports, you want a full application proxy that acts as an “agent” fronting the device. In this case the intermediary is trusted and already should have the necessary keys.

#2 could be done with ACLs based on information in things like MUD profiles, but I’d argue a better approach is something similar to STUN, but whose purpose is for the device to install filtering or rate-limiting state in a cooperating device “upstream of it”.

My 2¢, FWIW…

DaveO

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jan 2020 15:13:55 +0100

> On 21 Jan 2020, at 14:49, David R. Oran <[email-masked]> wrote:
> 

Certainly not with TLS 1.3, and that is by design.  With TLS 1.2 it’s possible, but then we end up with divergent code bases, and I would like to avoid that.

> To prevent “packet of death” scenarios where either bugs or malware can be exploited by a single crafted packet making it through to a vulnerable device.
> 
> To mitigate DoS attacks against devices that are not prepared to discard traffic effectively, either due to processing or energy considerations.
> 
> 1 is quite difficult to achieve without full middle-box functionality
> 
Wellll…. It depends.  Again, I’m reminded of Hitchhiker’s Guide to the Galaxy: “Space,” it says, “is big. Really big.”  Same with IoT.  If we’re talking about a digital twin strategy or some cloud-based service, the chances are ACLs are good enough, so long as you can identify the correct ACLs.

But… if the threat here really is the device itself in its fully functional form without any malware, then you need a full scale ALG to defend against it.  That’s something that we need to be thinking about.

> 2 could be done with ACLs based on information in things like MUD profiles, but I’d argue a better approach is something similar to STUN, but whose purpose is for the device to install filtering or rate-limiting state in a cooperating device “upstream of it”.
> 

It’s a matter of who you want making the claim.  If it’s the device, then STUN or another half dozen protocols can do the job.  If it’s the manufacturer who designed the thing, then MUD is the right tool.