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

Eliot Lear <> Mon, 20 January 2020 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03F781200B7 for <>; Mon, 20 Jan 2020 06:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QIwuhSjLnAz0 for <>; Mon, 20 Jan 2020 06:52:04 -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 E11D312007A for <>; Mon, 20 Jan 2020 06:52:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8426; q=dns/txt; s=iport; t=1579531924; x=1580741524; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=MCQBM5Zc+RF/uf0GWkT3u22FMNOwdebn9QGWbwwYGjg=; b=g8UOP3ILPJPBVkCGOX0rLxR6rNO89vUQ+E0TLzaV6Xg6yQCxgKtFx25c 6AzKtlcMhCI4gRDvZbsFAqyL9TQL3vvxNblgHmZMK+Ph8GI86oY+aAo9R vZ8xi1XNYzzmWZFFwkb3V6EzrMs24eLwKTkZKbkTehy2iSj+PeVjFYQeH Y=;
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="22262497"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jan 2020 14:52:01 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 00KEq0hH006353 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 14:52:01 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_A742C58C-FC81-4B32-9CD0-C6030839485E"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 20 Jan 2020 15:52:00 +0100
In-Reply-To: <>
Cc: Lars Eggert <>, "" <>, "" <>,
To: Василий Долматов <>
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 14:52:09 -0000

Hi Василий

> On 20 Jan 2020, at 15:09, Василий Долматов <> 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.