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

Eliot Lear <> Mon, 15 July 2019 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 908061200F4 for <>; Mon, 15 Jul 2019 05:20:56 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S03S2TnYjd-v for <>; Mon, 15 Jul 2019 05:20:54 -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 10841120112 for <>; Mon, 15 Jul 2019 05:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5617; q=dns/txt; s=iport; t=1563193254; x=1564402854; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=8EEQFK1vDpWmqyeMf6E2Q6FR2oye2HmULv8hg9ozJIs=; b=SqzCRANDMWb/7bL/YfkGkisRDjVaqPQNNKJEjV6k+eJaYtZNKrA819Wh doHPTzuenF9YMfqsILxI33IZifk2fzu6G5lVk8/1Jy0iWmeehYALM1Bs7 o9IphBKfJrViqQ/Lk5aTjhwnyPfhKBd+KDYUUm+gfCqR0R/Jk+e7/o/H6 4=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAAAmbyxd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBg1EBIBIohByIe4tUJZJ6h34CBwEBAQk?= =?us-ascii?q?DAQEvAQGEQAKDBjcGDgEDAQEEAQECAQVthUiFSgEBAQECASNUAgULCwQKCio?= =?us-ascii?q?CAlcGExSDDgGBew+rM4EyhUeEZhCBNAGBUIg7gWqBf4ERJwwTgh4uPodOMoI?= =?us-ascii?q?mBJRxlXIJghuCH4EMhG+LchuCLZVdoXqDCwIEBgUCFYFmIj6BGjMaCBsVZQG?= =?us-ascii?q?BWWg+gg8XFI4PPQMwkCsBAQ?=
X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="asc'?scan'208,217";a="14319685"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 12:20:51 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x6FCKoJc026171 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 12:20:51 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_03E7ABDC-DD4F-4485-B749-C998451B2639"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 15 Jul 2019 14:20:50 +0200
In-Reply-To: <>
Cc: Stephen Farrell <>,, Kathleen Moriarty <>, Dominique Lazanski <>, IETF SecDispatch <>
To: Eric Rescorla <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
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: Mon, 15 Jul 2019 12:20:57 -0000

Hi Eric,

> On 15 Jul 2019, at 13:31, Eric Rescorla <> wrote:
> When you say “network” do you mean the botnet or the wired network connecting devices?
> Well, from the perspective of the receiver of traffic, these are kind of the same thing, because you're just receiving packets.
> I agree it's a bit of an awkward fit, and I wish 3552 talked more about compromised counterparties -- this is mostly due to my comsec orientation, I agree -- but I'm not sure that it would change what work we do…

Right.  From the perspective of 3352 I would have to agree as well, because it is about security considerations relating to a specific protocol mechanism that we are defining and not a broad device threat model.(*)

That having been said, I still think the iRtf should be looking more at the latter with an eye toward finding new mechanisms that might improve the overarching Internet security posture.  Sorry for beating this drum, and I realize that there are often better publication venues for academics, but the IRTF can inform the IETF and broader community about what the threats are, and maybe even how to plug them in an economical fashion.


(*) Parenthetically while it’s amazing how long that doc has withstood the test of time (congratulations!), 3552 probably could use at least a review for other reasons.  The IETF has delivered some really good capabilities in the last 16 years, and some of those, like TLS 1.3 and QUIC probably deserve honorable mention.  I also wonder whether we should be pushing common coding approaches in terms of REST, etc, rather than people reinventing approaches.