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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 15 July 2019 13:08 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: smart@ietfa.amsl.com
Delivered-To: smart@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1477912004C for <smart@ietfa.amsl.com>; Mon, 15 Jul 2019 06:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pn96dKel5uQZ for <smart@ietfa.amsl.com>; Mon, 15 Jul 2019 06:08:26 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C45512011B for <smart@irtf.org>; Mon, 15 Jul 2019 06:08:25 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id n5so16892743otk.1 for <smart@irtf.org>; Mon, 15 Jul 2019 06:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NiH7quLBgk+PF83LxOGVwFuKuQXFIuYoyp7V6hpdEe4=; b=UeLHFMuuUY/xGDDI3U7ebfJ5sN9q9GMqC0DfZR5eg0lYXVDm8t6PhnCbmJaSfOFaJv V7Nw6F6DAr8Fs8QFaa7w3vINgmZ8mJpb+r7VFtXxk4VsOWQYSAwwl7hqW8wJ5wT0WK+q mCsrYFg76QzzEv5EiMlytHmzEqXcC+8gr/6di0DfYidcO9O+y7fvQM3kLSKgKlHFHx7h lWRFSHjrXnvYqxdoLkuumVDwiWEqKfVLk831ixTq9KOHb3CBPtlsYigSi3ch/zCSbxNB aQp3hGDez6P2As0qXN08qXgQ9BoA5DEQgSIle6ILDwtzrz/vKcNd6YWdX+yM/O2TAlcZ H1IQ==
X-Gm-Message-State: APjAAAVdgHPz/9UPvEcDDmcUaVA36UtE1U1vVtupdUVScdyLqXgFVAcZ dZMFo/NaOkg1ZnGmjArH3vnpozMd8KTgkCYAtqQ=
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: <0A8948DB-F97C-4F68-9173-7E627FB5019C@lastpresslabel.com> <4B10655B-8753-4B10-ACC9-16D7F78AD9F9@gmail.com> <CAMm+Lwh3KW6ZBbMktwmLcKyY8=_ysLYJF_7MsAuiOat6baQ=Kg@mail.gmail.com> <B551EF79-7E6E-4C4E-ADCA-6538F7972222@gmail.com> <CAMm+Lwg+2RFiXK43nJv7pD3OgM8y=ziVYxBkXD3F2kJyz37SxQ@mail.gmail.com> <50E59504-CA00-4792-AA72-FC08051E2486@gmail.com> <CAHbuEH5WUv-a4nKt5YAZosO-vE773Jh3xn1+-hA=4J7RBERc3g@mail.gmail.com> <78ccb680-9ccb-f13f-0442-02833cc7cc92@cs.tcd.ie> <CABcZeBNwmitpkJn0fCbNHOJtJ25yXdk6i6U9wK0a-9hwK1Tqcw@mail.gmail.com> <D484DBE1-8136-42C6-882C-307DC48E06DE@cisco.com> <CABcZeBPrhs+UmWgEu7M8g_6j3+Yzp0+wkz0_OTtvnuUmCUFwSw@mail.gmail.com> <F17D1910-38B1-4919-8C67-E8902C155099@cisco.com>
In-Reply-To: <F17D1910-38B1-4919-8C67-E8902C155099@cisco.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 15 Jul 2019 09:07:48 -0400
Message-ID: <CAHbuEH4E2Q6WhCpHvbwBqLQFFusXp0Rp6ozuaW4twN6=mBd5Hw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, smart@irtf.org, Dominique Lazanski <dml@lastpresslabel.com>, IETF SecDispatch <Secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008413a2058db7f43f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smart/M1KhxktN6nUrdK2t9m_qhEQCYns>
Subject: Re: [Smart] [Secdispatch] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-BeenThere: smart@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Stopping Malware And Researching Threats <smart.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/smart>, <mailto:smart-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smart/>
List-Post: <mailto:smart@irtf.org>
List-Help: <mailto:smart-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/smart>, <mailto:smart-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 13:08:29 -0000

On Mon, Jul 15, 2019 at 8:20 AM Eliot Lear <lear@cisco.com> wrote:

> Hi Eric,
>
> On 15 Jul 2019, at 13:31, Eric Rescorla <ekr@rtfm.com> 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
monitored.

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,
Kathleen


>
> 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,
Kathleen