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

Kathleen Moriarty <> Mon, 15 July 2019 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 618CA12004C for <>; Mon, 15 Jul 2019 06:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PWWrlSFLgeKr for <>; Mon, 15 Jul 2019 06:08:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09F5C12008B for <>; Mon, 15 Jul 2019 06:08:25 -0700 (PDT)
Received: by with SMTP id o101so16856158ota.8 for <>; Mon, 15 Jul 2019 06:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NiH7quLBgk+PF83LxOGVwFuKuQXFIuYoyp7V6hpdEe4=; b=W0xlhsoVnlbC5wCrGliKoXX0X/uIhSWJ7Jm3BNfvSkuV1mb7D920BJOQn2SSjnfbj8 HaV6mFewp8ZjDiHe5t0Nh5uOEyXXFLa4E/Kc31nUTz3PFqIun3KCsfgt67vMftj2hFj6 xFQv7SJqLXxzvvIR9LqUzfo9V1Ji6Wxi2bH8PUsIwQw0UruX8aJumhVBh58kWOjZ+tL3 dX+PT6lFvKoWjnpqb7PZlB2PwJB8VZIzgzNcB3leua9tUHOk9vvBYkXfnIKxrbocFExS GzThySm3/sgaZsccCqW8w9tZ9w4ARiMK+HbPTa5mMu7sWJurSqDo8Z3tFIK4S/SBe2Ap Ddcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NiH7quLBgk+PF83LxOGVwFuKuQXFIuYoyp7V6hpdEe4=; b=CpTMpv/L38AP6Tzi6jSIiqpOPzzsDUB59texdhobh6+s5y13RQmbGZvQtKWy6VZX10 k4Ng1MTIt2i4jkJkPcxr/MakXEdJ1oHfaj6vBNoEQQg+zAeN44vU0V9Ot4MopdP0loaL fFxE6hYUE3tHUEUYTHhxETRqIS3BPUOZmeKSBTqTMOeb0cEbd3cUfRq7F8FtPaAcBGLQ wC4FT1hDoIov9XQWgrj3NFQpkttXYX0Ivnw7wcg12FG0Xw7eIrK568sBu3XUN2GVm2Xr x+QBKCFqGX0qGeLc9vllVn/V8/uFvqKqWF7vkt9GOnxQFgw2OTEQ9wMDrhJfAzyYo7ZT vi6A==
X-Gm-Message-State: APjAAAUQAf/oDcNaMZHxDrcCX847ZZHfoEMHM2mRf/A6cVRqQND+ch0t LuCFCH5enEVKSj5FnYTIuTsZPwP55shEWDQxCW8=
X-Google-Smtp-Source: APXvYqwdyJHagCX8F9MdQisJMyQVhR5Imju16OGYBdFfvV//32J6ZZ1EN4M0s/IH0Wk+BQMHaiyDbQ9hMIhDSRt44LY=
X-Received: by 2002:a05:6830:210f:: with SMTP id i15mr19853194otc.250.1563196104379; Mon, 15 Jul 2019 06:08:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kathleen Moriarty <>
Date: Mon, 15 Jul 2019 09:07:48 -0400
Message-ID: <>
To: Eliot Lear <>
Cc: Eric Rescorla <>, Stephen Farrell <>,, Dominique Lazanski <>, IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="0000000000008413a2058db7f43f"
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 13:08:28 -0000

On Mon, Jul 15, 2019 at 8:20 AM Eliot Lear <> wrote:

> 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.(*)

The work areas for security have expanded out since 3552 was written and
the security area largely has 2 focus groups now.  The SACM, RATS, and
incident response work such as MILE and DOTS cover some of these points
that could better fill out a revision of 3552 along the lines of what this
draft is getting at.  My hope is that this will help with traction for work
to improve control management and attestation adoption as SACM and RATS
progress (MUD too).  Eliot pointed out NEA, there have been efforts
previously that have had limited adoption that help in these scenarios.
The time to detect attacks in well managed networks with tight monitoring
of security controls is significantly less than those that are not

These are IETF and not IRTF efforts, but a change in the threat model and
more focus in 3552 could be beneficial.  There are thousands of YANG
modules that went through to publication where it was possible to add
monitoring capabilities for security related configurations, but this
didn't happen.  If the IETF expressed this as a concern and area of focus,
we get get more people interested to do the work.  Since controls will
shift to the endpoint with strong encryption, the shift in control
management to the endpoint and us ensuring it's baked in where possible
will aid in the adoption of strong transport encryption.

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

I do think there is work for the IRTF as well and would like to see that
encouraged.  The shift to strong encryption is good, but upends the current
security management models for many.

Best regards,

> Eliot
> (*) 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.


Best regards,