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

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]> 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 example.com 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
liability.

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




> 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
> > [e-mail]
> >
> > Software longa, hardware brevis
> >
> >
> >
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>