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

Eliot Lear <> Mon, 20 January 2020 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA84A120937 for <>; Mon, 20 Jan 2020 09:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.502
X-Spam-Status: No, score=-12.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_SCAM=1.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xsql7F8UtOOa for <>; Mon, 20 Jan 2020 09:00:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 314C21200A1 for <>; Mon, 20 Jan 2020 09:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11724; q=dns/txt; s=iport; t=1579539629; x=1580749229; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=cCXrN348qgqXAbh3UIpLsY1ednEDRR3FHp1I34+0XPI=; b=YEvsFaAIh+q5W2L7Q8k8YRh3vXItLa/Gti0rE2+uF7DqLvq3nu5+G9Hw MKEhnwoTOodOY/u5F0HZYT3wsSxmVUROfJyd7XbAdPUrjL15oUUAlMy8j FEfA7Hf9NB/l8TCOSGU2GcsYAYPihW3UDqUT4f0psEDTelEKJAkVXY7kQ o=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.70,342,1574121600"; d="asc'?scan'208,217";a="22270281"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jan 2020 17:00:27 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 00KH0Pho017141 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 17:00:26 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_092C72A0-1CF3-46BE-97A7-907A73A41C5C"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 20 Jan 2020 18:00:25 +0100
In-Reply-To: <>
Cc: Василий Долматов <>, "" <>, Dave Oran <>, "" <>
To: Lars Eggert <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Lwip] [T2TRG] QUIC on IoT boards
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jan 2020 17:00:43 -0000

Hi Lars,

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