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

Phillip Hallam-Baker <> Sun, 14 July 2019 15:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6A0512024B for <>; Sun, 14 Jul 2019 08:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N_oN9GnqemPc for <>; Sun, 14 Jul 2019 08:20:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9433212003F for <>; Sun, 14 Jul 2019 08:20:49 -0700 (PDT)
Received: by with SMTP id z23so14280285ote.13 for <>; Sun, 14 Jul 2019 08:20:49 -0700 (PDT)
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=nQD/MRjP7UUvLpnoULuqr924TNWdvioDZgC8zKt1254=; b=iu4zkIDIdmJP04b5HD5j6rUWBiDcpsaJCWdxe/ZBkmX07J8YVaS0kyU9HRVFoPLJik DOU9NkEzX2X2FnbXuOuWuYUKj7YuBGzX4mm4SxhtVQ4VUNAlp3lV65uVLZw8CPltpGoZ UvdSopJBM7FEdf1FvtjPt7VFSdH4zFkySG0zpeXEz+Ss6c0FPs17dXTdj7eYdj9ddUww igGuV99tkO0XVwXBy8cITPYufhj2fTGsGUaFm63BJUcj3P2PohU9ratUEbjakvyyXnx5 HaELwVZT6wP2AJvvI4gDosEGqQqCYjHoTYCO/brF0tKBLxVRz5nNDt0i+gYX8py6jn2c LhYA==
X-Gm-Message-State: APjAAAXWTxebTGfxjRYaM6zCv3z8ueJWSqWMobkHpFVyV0b6dVQUv4HC VXRCZrvgi0eDek5/uaoCDf/4MGEw4EWWUunQ8jI=
X-Google-Smtp-Source: APXvYqyLiA8fLNuxSiE9GCuuSbnLav7nmpROMRxG7JVpoBUmmIr2LvH+TTr+jK/YjXWRk2YuMeVskAp9G9FZpW7XDbU=
X-Received: by 2002:a05:6830:1206:: with SMTP id r6mr16785932otp.37.1563117648859; Sun, 14 Jul 2019 08:20:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Sun, 14 Jul 2019 11:20:37 -0400
Message-ID: <>
To: Eliot Lear <>
Cc: Melinda Shore <>, IETF SecDispatch <>
Content-Type: multipart/alternative; boundary="00000000000033d5ca058da5b02e"
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 15:20:52 -0000

Mostly +1. But this is relevant to the topic I asked for time for...

On Sun, Jul 14, 2019 at 6:56 AM Eliot Lear <> wrote:

> Hi Melinda,
> >  We
> > typically deal with wireline protocols and their support
> > structures, and I'm hoping that as the discussions progress
> > people can be clear about what they'd like to see from the
> > IETF.
> I think you’re primarily referring to leaky user databases here.  I agree
> with you that we cannot fix organizations’ bad internal code with a
> wireline protocol.

I can. That is exactly what I am working on.

This is why I am distinguishing between the server host and the client
endpoints. I can't do anything about Alice's laptop or desktop. If that
gets malware: not my problem.

But I can solve the problem of the data being breached on the server and
this is in scope because a server is not an endpoint. Servers are
middleboxes, not real endpoints. If you apply end to end cryptography in
the right way, you can ensure that all that you have on the server host is
AES256 encrypted data and a bunch of random numbers.

We are having all these breaches because common business processes require
confidential data to be used in ways that existing CRM doesn't solve and
can't solve unless there is an open standard. Most of the really important
information has to cross organizational boundaries. Almost every important
conversation will end up being with a customer, a provider, the auditors or
external counsel.

Alice at is working on the health care plan. She creates a
spreadsheet to assess the cost impact of the different plans and it gets
stored on the file server which is then breached when any one of the 10,000
employees with access to files on it clicks on the wrong link in an email.

> However, to exploit the vulnerability, the attack had to come from
> somewhere.  We already have one mechanism to address profiling with IoT
> that manufacturers can use to keep their systems from being exploited as
> BoTs.

The vulnerability has to come from somewhere and it often has to
re-propagate after the firewall is breached.

The distinction between the network and the Internetwork is a critical one
in security terms but one that somehow became unmentionable in the IETF.
Which is really odd if you have watched Einer Stefferrud's presentation on
the Internet architecture.

I have a completely different degree of control and responsibility when it
comes to my network. The Internet has to be able to pass any IP packets
regardless of port etc. But that is not the case for my network. I so not
want my Internet connected blender having the ability to act as a staging
post for a botnet.

So in the Enterprise or in the home, restricting what a device can do on
the network on a default deny, need to know basis is powerful.

Sure, personal computers and servers are going to require a lot more
network capabilities than food blenders. But there will be orders of
magnitude more IoT devices.

The next question is whether we should be promoting or improving other
> mechanisms to provide people at home and elsewhere more visibility in terms
> of what their general purpose computing devices are doing.  I’m thinking of
> PCP in particular.  And while there may be more we can do, there may also
> be some limitations relating not only to privacy but also economics of web
> services.

I am waiting for folk to realize that all this data they have been
collecting is not the goldmine they think, it is steaming piles of

Sure, my personal data was really useful for targeting ads at me. Right up
until there were dozens of companies could do the same. Now it is a GDPR

> What I like about Dominique’s draft is that it gets us thinking in those
> directions (or at least it did me).
> >
> > I do think that some of this may be appropriate for opsec,
> > as well, or at least should be called to their attention.
> Or an RG or a side meeting.  It would be fun to continue the discussion.
> Eliot
> >
> > Melinda
> >
> > --
> > Melinda Shore
> >
> >
> > Software longa, hardware brevis
> >
> >
> >
> _______________________________________________
> Secdispatch mailing list