Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Eliot Lear <> Sun, 14 July 2019 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA1B712016D for <>; Sun, 14 Jul 2019 13:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=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 SUkxzBnhfslt for <>; Sun, 14 Jul 2019 13:08:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDC16120165 for <>; Sun, 14 Jul 2019 13:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10927; q=dns/txt; s=iport; t=1563134900; x=1564344500; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=SzeunUv/OkbHxFq/Q+HIGPeqCbS205bQ+c90iX9vsdg=; b=msoXDc5m28KjcZAfX/oUk6eGjDDhvAYbIELHWjxdK8Wm2gNDDU9fNFzE eMuBnXXfpp8jwhkzVAugC5wtJoK9sD5NIa8JNzRVm8F/aGKKzheCVhBEZ p4OeR2UDfjg/za3VXbq0wZwuiOrZEcAkQcYbL3jhexQ6NfoD0Vk/NLf5t o=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAAAIiytd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBZ4FrMiiEHIh7i3iSeod+AgcBAQEJAwEBLwE?= =?us-ascii?q?BgUuCdQKCeTcGDgEDAQEEAQECAQVthUiFSgEBAQECASNQBAIFCwsYKgICVwY?= =?us-ascii?q?TgyIBgXsPqkWBMoVHhGUQgTQBgVCHRXaBaoF/gREnH4IeLj6HTjKCJgSMKYh?= =?us-ascii?q?IlXIJghuCH4EMkGEbgi2HJYNlhkGEEqF6gwsCBAYFAhWBZiI+gRozGggbFWU?= =?us-ascii?q?BgVloPoIPFxSODz0DMJAkAQE?=
X-IronPort-AV: E=Sophos;i="5.63,491,1557187200"; d="asc'?scan'208,217";a="14292506"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2019 20:08:17 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id x6EK8Gd5011889 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jul 2019 20:08:16 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_03BA5F2C-51BA-46A7-B956-A3808734AF84"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 14 Jul 2019 22:08:15 +0200
In-Reply-To: <>
To: Melinda Shore <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Jul 2019 20:08:23 -0000

Hi Melinda,

> On 14 Jul 2019, at 21:18, Melinda Shore <> wrote:
> On 7/14/19 2:56 AM, Eliot Lear wrote:> I think you’re primarily
> referring to leaky user databases here.
> No, to the entire draft.

I leapt to that point erroneously, but in an attempt to think about a problem that was tractable.  (Well, at least not boiling all oceans at once).  It may be too early to do that, but that’s where my head went.

>> However, to exploit the vulnerability, the
>> attack had to come from somewhere.
> I sincerely hope that you're not arguing that anything
> that happens on an endpoint is within the scope of the
> IETF if that endpoint is network-attached.

I made no such statement.  In fact, I would hope one could reasonably infer the opposite from the previous adjoining sentence:

>>  I agree with you that we cannot fix organizations’ bad internal code with a wireline protocol.

To your point below, there are three questions we can ask:

Is the device known to be compromised?
Is the device not known to be compromised?
Is the device in a known good state?

RATS definitely looks at the 2nd, possibly the 3rd.  I’m sure there’s a lot of growing room between those questions alone, some of which is likely in the IETF’s wheelhouse.  That having been said, see below.

>> We already have one mechanism to
>> address profiling with IoT that manufacturers can use to keep their
>> systems from being exploited as BoTs.
> We also had the work done in Network Endpoint Assessment.
> Both of these things are on-the-wire protocols and something
> that we can do something about.  However, the only things I
> saw in the draft that was something that might be within
> the IETF's purview is related to software updates, and aside
> from SUIT there's work on this going on elsewhere.  Although
> if someone wants to make the case for software transparency
> logging, please do it soon before trans shuts down).

NEA is dead.  Long live NEA. But remote attestation is just getting going.  And there may be other approaches to build on RATS, SUIT, EAT, etc. that are worth exploring.

>> Or an RG or a side meeting.  It would be fun to continue the
>> discussion.
> I'm not sure that's clear.  It's my own opinion that the
> charter that's been proposed so far for a research group would
> need a massive rewrite and that the folks advocating this work
> really don't want to change much to make it more suitable for
> chartering as an RG.

You apparently have had more conversations with them than I have (that wouldn’t be hard.  In my case I’ve had exactly none).  I thought of a research group because Dominique's draft talks amongst other things about the need for …  research.  And so you’ll forgive me if I am experiencing just a bit of cognitive dissidence between the draft and your perception about advocates of this work.  I’ll accept that as my own lack of context.

> If you want to continue as a side
> meeting I guess that's your business, but in the meantime opsec
> does exist.  It's currently focused on network devices but I
> think it may be worth talking with them.

The issue with opsec is that they are focused on best practices, and cannot create any protocol.  Unless there is a best practice that can address Dominique’s points, it’s the wrong place.  And worse, I suspect many of those best practices have been written, mostly elsewhere, and are simply not followed.