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

[Eliot Lear <[e-mail]>]

Hi Lars,

> On 20 Jan 2020, at 16:08, Lars Eggert <[e-mail]> wrote:
> 
> Hi,
> 
> On 2020-1-20, at 16:52, Eliot Lear <[e-mail]> 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 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.
> 
>> 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.

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 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.

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.

> 
>> 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.
> 
> 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