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

From: Bret Jordan <[email-masked]>
Date: Wed, 10 Jul 2019 09:29:04 -0600

Dominique,

I have read over your draft, and I think it highlights some very key things we all need to look at and address. Thanks for putting these ideas down on paper.  Hopefully this I-D can help us all start a broader discussion to improve things.

SMART / SecDispatch,

If you have not yet read this I-D, I would encourage you to look at it.  It is a very fast read. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 8, 2019, at 12:54 PM, Dominique Lazanski <[email-masked]> wrote:
> 
> Cross posting to this mailing list.
> 
> Dominique 
> 
> A new version of I-D, draft-lazanski-smart-users-internet-00.txt
> has been successfully submitted by Dominique Lazanski and posted to the
> IETF repository.
> 
> Name:        draft-lazanski-smart-users-internet
> Revision:    00
> Title:        An Internet for Users Again
> Document date:    2019-07-08
> Group:        Individual Submission
> Pages:        12
> URL:            https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt <https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/ <https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/>
> Htmlized:       https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00 <https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet <https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet>
> 
> 
> Abstract:
>   RFC 3552 introduces a threat model that does not include endpoint
>   security. In the fifteen years since RFC 3552 security issues and
>   cyber attacks have increased, especially on the endpoint. This
>   document proposes a new approach to Internet cyber security protocol
>   development that focuses on the user of the Internet, namely those
>   who use the endpoint and are the most vulnerable to attacks. 
> -- 
> Smart mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/smart

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Thu, 11 Jul 2019 07:27:35 +0000

Likewise, I read this I-D and it puts the finger on the right nerves. Thank you for putting this one in place.

Indeed it is very straightforward read

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday 10 July 2019 17:29, Bret Jordan <[email-masked]> wrote:

>> URL:            https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/
>> Htmlized:       https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet
>>
>> Abstract:

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Jul 2019 21:22:47 -0400

It is an interesting read. But I see a very important distinction that
needs to be made between compromise of user end points and compromise of
server end points.

Most breaches that occur are when an enterprise is penetrated and the
firewall is the first and last line of defense. So Percy the Pinhead clicks
on a link in an email and six hours later the attacker has root privilege
on the corporate server. This is not Percy's fault, the fault is that a
single mistake by a single employee results in compromise of data Percy was
never authorized to access.

So right now we have systems where one compromise at any one of 10,000
endpoints results in a breach.

Now lets consider using some 1980s style end to end cryptography. So that
the ultra important recipe data is only available to the dozen members of
group. This improves matters because we have reduced the points of
compromise from 10,000 cooks and service staff to 12 trusted employees.

That is a start but we are still vulnerable to a single end point
compromise so lets apply threshold cryptography so members of group W only
have one half of the decryption key, the other is on the server and both
halves of the key are needed to perform decryption. In this scenario, we
now require two separate compromises of two different end points.

On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan <[email-masked]> wrote:

> Dominique,
>
> I have read over your draft, and I think it highlights some very key
> things we all need to look at and address. Thanks for putting these ideas
> down on paper.  Hopefully this I-D can help us all start a broader
> discussion to improve things.
>
> SMART / SecDispatch,
>
> URL:
> https://www.ietf.org/internet-drafts/draft-lazanski-smart-users-internet-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-lazanski-smart-users-internet/
> Htmlized:
> https://tools.ietf.org/html/draft-lazanski-smart-users-internet-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-lazanski-smart-users-internet
>
>
> Abstract:
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 12 Jul 2019 10:04:55 -0600

Unfortunately I think you are misunderstanding the attack surface how attacks can work and wrongfully assume how threat actors and intrusions sets operate.  It is not always about exfiltrating your super secret “recipe" as you call it.  So database encryption will not always help you, nor will putting your database on a block chain. Yes, it can reduce the attack surface or exposure of your data under legitimate use. But once the server is compromised, the attacker can simply pull decrypted information from memory. Or can continue to move laterally through the organization and pull the data of endpoints that do have access to the data.  Further, the threat actor may not be interested in exfiltrating the data at all.  But may simply be interested in using your “1980s” crypto as you call it to encrypt your database with their own key.  This attack is commonly called Ransomware. 

The key point is that you can not patch your way into security.  This is a common misunderstand that many people have outside of operational security.  End points are always weak and highly vulnerable to attack.  It does not matter if they are end user devices, servers, IoT devices, or components soldered in to SCADA systems.

I would encourage you to look at the MITRE ATT&CK framework to better understand how these attacks work and how threat actors can disrupt, exfiltrate, and destroy a company. 

We have to realize that the security model has changed since some of these documents were written. Yes, pervasive monitoring of users on the internet is a problem, but it is only 1 piece of a large pie of problems.  We in the IETF need to communicate better with operational security, so that we can design solutions that hollistically help improve security and not make one part better at the huge expense of everything else. 

Thanks,
Bret

> On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> It is an interesting read. But I see a very important distinction that needs to be made between compromise of user end points and compromise of server end points.
> 
> Most breaches that occur are when an enterprise is penetrated and the firewall is the first and last line of defense. So Percy the Pinhead clicks on a link in an email and six hours later the attacker has root privilege on the corporate server. This is not Percy's fault, the fault is that a single mistake by a single employee results in compromise of data Percy was never authorized to access.
> 
> So right now we have systems where one compromise at any one of 10,000 endpoints results in a breach. 
> 
> Now lets consider using some 1980s style end to end cryptography. So that the ultra important recipe data is only available to the dozen members of group. This improves matters because we have reduced the points of compromise from 10,000 cooks and service staff to 12 trusted employees.
> 
> That is a start but we are still vulnerable to a single end point compromise so lets apply threshold cryptography so members of group W only have one half of the decryption key, the other is on the server and both halves of the key are needed to perform decryption. In this scenario, we now require two separate compromises of two different end points.
> 
> 
> On Wed, Jul 10, 2019 at 11:29 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> Dominique,
> 
>> On Jul 8, 2019, at 12:54 PM, Dominique Lazanski <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/smart <https://www.irtf.org/mailman/listinfo/smart>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Jul 2019 14:40:39 -0400

Applied properly, the cloud service never has anything but encrypted data
and a pile of random numbers.

Mesh group encryption is genuinely end to end. There is never plaintext on
the server. The server never has sufficient information to decrypt.
Assuming only that the random numbers used to split keys are unguessable,
the system is information theroretic secure with respect to the requirement
for two keys to be used to decrypt.

There will always be an endpoint vulnerability in that data has to be
decrypted to present it to the user, edit it, etc. But reducing the attack
surface from every server and every endpoint in the enterprise to the dozen
or so endpoints with a need to know the information is powerful.

I have not considered the ransomware issue in depth because the solution is
pretty obvious - take backups, verify the ability to recover at regular
intervals. That said, obvious solutions can be very complex to deploy.

This is actually one of the very few applications that Blockchain or at
least the Haber-Stornetta hash chain could help us with. A DARE container
is an append only log with optional Merkle Tree integrity checking. So we
can do a continuous backup to a write only storage array behind a very very
simple and limited firewall that only allows the backup requests through.
If the online system is compromized, we recover from the firewalled,
write-only array.

Getting to that point in the mesh is likely to take five years. But
Microsoft owns GitHub. And Git could at least in theory be extended to
provide some of this functionality.

Alternatively, bring down the BitCoin infrastructure by auditing Tether and
the payment infrastrastructure that makes ransomware profitable would be
gone.

On Fri, Jul 12, 2019 at 12:05 PM Bret Jordan <[email-masked]> wrote:

> Unfortunately I think you are misunderstanding the attack surface how
> attacks can work and wrongfully assume how threat actors and intrusions
> sets operate.  It is not always about exfiltrating your super secret
> “recipe" as you call it.  So database encryption will not always help you,
> nor will putting your database on a block chain. Yes, it can reduce the
> attack surface or exposure of your data under legitimate use. But once the
> server is compromised, the attacker can simply pull decrypted information
> from memory. Or can continue to move laterally through the organization and
> pull the data of endpoints that do have access to the data.  Further, the
> threat actor may not be interested in exfiltrating the data at all.  But
> may simply be interested in using your “1980s” crypto as you call it to
> encrypt your database with their own key.  This attack is commonly called
> Ransomware.
>
> The key point is that you can not patch your way into security.  This is a
> common misunderstand that many people have outside of operational
> security.  End points are always weak and highly vulnerable to attack.  It
> does not matter if they are end user devices, servers, IoT devices, or
> components soldered in to SCADA systems.
>
> I would encourage you to look at the MITRE ATT&CK framework to better
> understand how these attacks work and how threat actors can disrupt,
> exfiltrate, and destroy a company.
>
> We have to realize that the security model has changed since some of these
> documents were written. Yes, pervasive monitoring of users on the internet
> is a problem, but it is only 1 piece of a large pie of problems.  We in the
> IETF need to communicate better with operational security, so that we can
> design solutions that hollistically help improve security and not make one
> part better at the huge expense of everything else.
>
>
>
> Thanks,
> Bret

---

From: Bret Jordan <[email-masked]>
Date: Fri, 12 Jul 2019 13:35:10 -0600

As with all things crypto, block-chain, quantum, cloud, and snake-oil, they are not ubiquitously deployable across the entire eco-system of end users, applications, enterprises, and governments.  You say that this can all be fixed in 5-years, I think you are off by an order of magnitude.  

Some organizations are still running Windows XP, some parts of critical infrastructure still have very old soldered in equipment.  Some critical applications and resources needed for regulatory compliance can take months to years to even get patched. What about cost optimized IoT devices that can never run any security software or have no plans of ever being updated?  What about direct to telco connections with 5G enabled devices? We still can not even patch end devices reliability without a risk of bricking them.  

The problem is not just about protecting data base data.  Yes, this is one piece in the entire security pie.  But it is not the only part.  Trying to distill things down to say that it is, gives a false sense of security.  Just like the hyperbole and dogma that if your connection is perfectly encrypted and free from external tracking, it is secure and safe. Threat actors including CDNs and services providers can still compromise the end user, end device, data, and track all of their where about and everything they do.

The attack surface and needs of end users and enterprises are much more extensive than a single point solution.  Yes, I have looked at your proposed Mesh network. It is very neat, and very cool.  I would love to work with you on it.  I see many places it can potentially be used.  But thinking that in 5 years everyone is going to forklift the entire Internet and go with your solution and single solution is not realistic.

This is the problem with the IETF as a whole.  Too few understand day-2-day operational security.  This is one thing that SMART really needs to help with.  We need to start a bunch of discussions and get a bunch of research done to help every aspect of the IETF.  We need to invite people from FIRST and other industry groups to help with this effort.  

Some think that SMART is a tiny amount of work.  But SMART could be one of the most important pieces of work that the IETF / IRTF does in the next 10 years. 

Thanks,
Bret

> On Jul 12, 2019, at 12:40 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Applied properly, the cloud service never has anything but encrypted data and a pile of random numbers.
> 
> Mesh group encryption is genuinely end to end. There is never plaintext on the server. The server never has sufficient information to decrypt. Assuming only that the random numbers used to split keys are unguessable, the system is information theroretic secure with respect to the requirement for two keys to be used to decrypt.
> 
> There will always be an endpoint vulnerability in that data has to be decrypted to present it to the user, edit it, etc. But reducing the attack surface from every server and every endpoint in the enterprise to the dozen or so endpoints with a need to know the information is powerful.
> 
> 
> I have not considered the ransomware issue in depth because the solution is pretty obvious - take backups, verify the ability to recover at regular intervals. That said, obvious solutions can be very complex to deploy.
> 
> This is actually one of the very few applications that Blockchain or at least the Haber-Stornetta hash chain could help us with. A DARE container is an append only log with optional Merkle Tree integrity checking. So we can do a continuous backup to a write only storage array behind a very very simple and limited firewall that only allows the backup requests through. If the online system is compromized, we recover from the firewalled, write-only array. 
> 
> Getting to that point in the mesh is likely to take five years. But Microsoft owns GitHub. And Git could at least in theory be extended to provide some of this functionality. 
> 
> Alternatively, bring down the BitCoin infrastructure by auditing Tether and the payment infrastrastructure that makes ransomware profitable would be gone.
> 
> On Fri, Jul 12, 2019 at 12:05 PM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 11, 2019, at 7:22 PM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 13 Jul 2019 22:06:58 -0400

Dominique,

Thank you for your work on this draft.  It's a good start toward broadening
the conversation on the Internet threat model and I do agree that is
necessary.

The other recent threat model drafts don't cover the points raised, but
none of the three threat model drafts cover all threats. I'm not sure if
there are other threat model drafts I have missed as well.

I like the focus, but think as the draft goes on, broadening the scope to
look at the full threat model would be very helpful towards something the
IETF participants might buy into (I could be wrong here, but this is what I
suspect).  We can't look solely at the end point as the IETF is concerned
mostly with on-the-wire protocols.  In some RFCs, there are clear
requirements on end point security, but this is not particularly common.
It would be good to see the sort of changes proposed added into a revision
of 3552 in my opinion.  However, we do need to think about surveillance and
other threats too.  One of DKG's points from a panel at RSA was that boxes
that intercept traffic and are capable of decrypting that traffic is a
target rich environment.  I agree with that point.

We are in a tough spot as crypto has become stronger, but the endpoints
have not become more secure or even capable of detecting the threats that
were blocked in-the-middle previously.  I think adding this point into your
draft would be helpful as we (as a community) rethink the threat model.

I'd be very happy to discuss this further.

Also - is this a request to present at SecDispatch?

Thank you,
Kathleen

Sorry for the top-post, but I was not responding the the thread besides
Dominique's initial message.

-- 

Best regards,
Kathleen

---

From: Melinda Shore <[email-masked]>
Date: Sat, 13 Jul 2019 21:04:02 -0800

On 7/13/19 6:06 PM, Kathleen Moriarty wrote:
> Thank you for your work on this draft.  It's a good start toward
> broadening the conversation on the Internet threat model and I do agree
> that is necessary.  

I think this discussion is extremely useful and I generally
agree with the bulk of the underlying assumptions, but I'm
trying to understand what the IETF can do about some of the
endpoint-related problems that are being called out.  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 do think that some of this may be appropriate for opsec,
as well, or at least should be called to their attention.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Jul 2019 11:25:53 +0100

Hiya,

On 14/07/2019 03:06, Kathleen Moriarty wrote:
> It's a good start toward broadening

FWIW, I don't agree that this is a good start.

ISTM that this draft is far too opinionated, for example
claiming that "IETF attendees are privacy-focused", (how
does the author know?), claiming it "unthinkable" that
something isn't done, and that "Internet security research
and technical development must accept the reality of all
the security issues in the Internet ecosystem" (though
I'm not sure I can parse that last quote at all).

Towards the end we get: "Endpoints have changed over the
last 10 years, but assumptions about endpoints in the IETF
hasn't changed in that time" - I don't know how the
author knows what assumptions may or may not be made
by IETF participants (not "attendees" of course).

And perhaps most oddly, this bold assertion: "Further, it
is imperative that new conclusions and recommendations
from a revisited threat model are backed up by research, case
studies and experience - rather than bold assertions." ;-)

The list of breaches and botnets is fine, but not much
use without any analysis of how those happened. We need a
good bit more work to figure out whether any changes to
protocols or protocol design are actually warranted or
useful in the face of these kinds of incident. (Hence
the oddity of the bold assertion above.)

Lastly, ISTM important, if any discussion here is to
be worthwhile, to recognise from the start that existing
IETF consensus positions in this space are not likely to
be discarded - those were arrived at after a lot iterations
of a lot of debate by well-informed IETF participants.
(Despite what some may claim;-) So I reckon the right
discussion to have is about how to extend and not discard
the 3552 threat model. Any other attempted changes would
seem to me to require a shift in deployments from 2-party
to multi-party protocols, which is unrealistic, or to
require magical trust in middleboxes, which would be plain
silly and seems highly unlikely to be something for which
IETF consensus would be established.

> Also - is this a request to present at SecDispatch?

I hope not. This draft is IMO clearly not ready for that.
An initial discussion about threat models and how to
approach this kind of work at saag may be worthwhile (and
I think Jari has asked the sec ADs for such a slot).

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Jul 2019 12:56:42 +0200

Hi Melinda,

>  We

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

What I like about Dominique’s draft is that it gets us thinking in those directions (or at least it did me).

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 14 Jul 2019 07:20:33 -0400

Hello,

> I'm not sure I can parse that last quote at all).

Sure, opinionated text gets cut as a draft progresses, but she makes a
clear case for adding in the endpoint into the threat model.  I had tried
to do a bit of that in my AD reviews as I agree, it's one of the places
systems are left vulnerable and open to attack. When the defenses in the
middle are removed, new ones are needed.  Protocol evolution is eliminating
these middle boxes, so the end point needs to be shored up.  We need first
to better prevent attacks, and then to be able to detect them at end
points.  Some of this could get baked into protocols (I'm not sure how yet,
but perhaps something can be done), requiring research and ensuring the
protocols maintain the existing set of desired properties.

> by IETF participants (not "attendees" of course).

Sure, there's a bunch of us that care about end points, but I think outside
perception doesn't show this and those who work solely on end point
security don't feel heard at the moment.  Bake this into a bigger threat
model and we have a more complete picture.  We as a community need to step
back and think about the threat model and impacts to users of the
Internet.  The time to detect an attack has come way down (in most
countries) over the last 2 years.  This isn't spelled out in the draft, but
could be in a comprehensive draft.  The reason for this is that
organizations have deployed tighter controls and are quicker to detect
anomalies on their networks.  Detection devices have also aided in this
reduction with the exchange of indicators of compromise.  We need new ways
to deploy prevention and detection mechanisms and can't ignore that as we
eliminate the methods of detection and prevention used by large numbers of
organizations.

I'd be happy to help flesh out this part of the threat model more.

> studies and experience - rather than bold assertions." ;-)

PM was backed by lots of information, I agree.  The problem is that the
focus ignored (largely) other security concerns.  I tried to ensure system
integrity came up when important in drafts and also logging, but maybe
there's more that can and should be done.

> the oddity of the bold assertion above.)

Yes, and these aren't the only types of attacks.  Phishing is accountable
for about 90% of so called APT attacks (I can find the artcile that says
this, just not at the moment).  Better authentication will help (FIDO,
tokbind, HOBA, etc.) , but some of the attacks don't involve
authentication.

> IETF consensus would be established.

Sure, my full message made the same point. We need to look at the broader
threat model and have a more comprehensive picture.  I do think this helps
make the case for the end point and figuring out if we have options within
protocols to prevent threat with out-of-the-box thinking, research,
security protocol proofing, and testing.

> I think Jari has asked the sec ADs for such a slot).

She sent it to SecDispatch, so I needed to ask.  I do agree it's better for
SAAG and a larger discussion on threat model, but that's for our ADs to
decide.

-- 

Best regards,
Kathleen

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Jul 2019 11:20:37 -0400

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 <[email-masked]> wrote:

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

---

From: Bret Jordan <[email-masked]>
Date: Sun, 14 Jul 2019 10:30:56 -0600

I personally think the biggest value at this stage is awareness and discussion.  So I would love to see this continue as a regular update item for sec dispatch.  I would also love to see regular and multiple side meetings.  I would also love to see SMART get officially chartered. 

I fully understand and get that we in the IETF generally focus on on-the-wire protocols.  However, I think we can design better and more secure solutions once we more completely understand the entire security pie.  Understanding operational security requirements and regulatory compliance requirements is critical for the success of the solutions we create here in the IETF.

Bret 

Sent from my Commodore 128D

> On Jul 14, 2019, at 4:56 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Melinda,
> 
>> We

---

From: Melinda Shore <[email-masked]>
Date: Sun, 14 Jul 2019 11:18:29 -0800

On 7/14/19 2:56 AM, Eliot Lear wrote:> I think you’re primarily
referring to leaky user databases here.

No, to the entire draft.

> However, to exploit the vulnerability, the
> attack had to come from somewhere.  

I sincerely hope that you're not arguing that anything
that happens on an endpoint is within the scope of the
IETF if that endpoint is network-attached.

> We already have one mechanism to
> address profiling with IoT that manufacturers can use to keep their
> systems from being exploited as BoTs.  

We also had the work done in Network Endpoint Assessment.
Both of these things are on-the-wire protocols and something
that we can do something about.  However, the only things I
saw in the draft that was something that might be within
the IETF's purview is related to software updates, and aside
from SUIT there's work on this going on elsewhere.  Although
if someone wants to make the case for software transparency
logging, please do it soon before trans shuts down).

> Or an RG or a side meeting.  It would be fun to continue the

I'm not sure that's clear.  It's my own opinion that the
charter that's been proposed so far for a research group would
need a massive rewrite and that the folks advocating this work
really don't want to change much to make it more suitable for
chartering as an RG.  If you want to continue as a side
meeting I guess that's your business, but in the meantime opsec
does exist.  It's currently focused on network devices but I
think it may be worth talking with them.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Jul 2019 22:08:15 +0200

Hi Melinda,

> On 14 Jul 2019, at 21:18, Melinda Shore <[email-masked]> wrote:
> 

I leapt to that point erroneously, but in an attempt to think about a problem that was tractable.  (Well, at least not boiling all oceans at once).  It may be too early to do that, but that’s where my head went.

I made no such statement.  In fact, I would hope one could reasonably infer the opposite from the previous adjoining sentence:

>>  I agree with you that we cannot fix organizations’ bad internal code with a wireline protocol.

To your point below, there are three questions we can ask:

Is the device known to be compromised?
Is the device not known to be compromised?
Is the device in a known good state?

RATS definitely looks at the 2nd, possibly the 3rd.  I’m sure there’s a lot of growing room between those questions alone, some of which is likely in the IETF’s wheelhouse.  That having been said, see below.

> logging, please do it soon before trans shuts down).

NEA is dead.  Long live NEA. But remote attestation is just getting going.  And there may be other approaches to build on RATS, SUIT, EAT, etc. that are worth exploring.

> chartering as an RG.

You apparently have had more conversations with them than I have (that wouldn’t be hard.  In my case I’ve had exactly none).  I thought of a research group because Dominique's draft talks amongst other things about the need for …  research.  And so you’ll forgive me if I am experiencing just a bit of cognitive dissidence between the draft and your perception about advocates of this work.  I’ll accept that as my own lack of context.

> If you want to continue as a side

The issue with opsec is that they are focused on best practices, and cannot create any protocol.  Unless there is a best practice that can address Dominique’s points, it’s the wrong place.  And worse, I suspect many of those best practices have been written, mostly elsewhere, and are simply not followed.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2019 14:24:29 -0700

I more or less agree with Stephen's position.

First, I recognize that this focus on secure endpoints talking to each
other is probably the part of 3552 that people are most unhappy
about. As I was almost certainly the person who wrote that text, it might
be helpful if I laid out some background.

First, RFC 3552 isn't intended to say that endpoint threats aren't
real, but merely that they are out of scope because they are hard
to address. Here's the text in context:

   The Internet environment has a fairly well understood threat model.
   In general, we assume that the end-systems engaging in a protocol
   exchange have not themselves been compromised.  Protecting against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to design
   protocols which minimize the extent of the damage done under these
   circumstances.

For a more narrow statement with a similar theme (but extended to
the Web platform, see
https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-
and
https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-compromised-infected-machines-in-Chrome-s-threat-model-
):

   This is essentially the same situation as with physically-local
   attacks. The attacker's code, when it runs as your user account on
   your machine, can do anything you can do. (See also Microsoft's Ten
   Immutable Laws Of Security.)

However, RFC 3552 is primarily oriented towards what can be
standardized and in particular towards protocols, and generally secure
protocols require some sort of TCB to be effective. Obviously, as
alluded to in 3552, to the extent to which protocols can be designed
to minimize damage, and we routinely attempt to do so. Examples of
this include the use of Forward Secure algorithms and trying to avoid
or mitigate designs with single points of failure (as with Certificate
Transparency).  I know that PHB has some ideas along these lines; I
haven't studied them enough to know what I think, but that sort of
thing is generally in scope as well.

This to some extent goes to Section 2 of draft-lazanski. I certainly
agree that to the extent to which it is possible to design
cryptographic solutions to prevent data breaches, it is useful to do
so, and protocols for doing that would potentially be in scope for
IETF. I say "potentially" because I'm not sure that (a) standards are
necessary in this space beyond the kind of work we are already doing
or (b) that we would have the community to define them, but I don't
see an in principle barrier [0] I certainly would not expect 3552 to
be deployed to preclude that kind of work.

Similarly, I don't think that the kinds of botnet attacks described
in Section 3 are out of scope for 3552, though I see how it could
be read this way. However I think that the idea of a malicious
counterparty is clearly in scope if we assume that the attacker
controls the network. Here too, I wouldn't expect 3552 to be deployed
to preclude that kind of work; we have done plenty of anti-DoS work
in IETF (whether it is good enough is a different story).

Turning now to the document itself, its language seems to be trying
to stake out a very strong position, but I'm not quite sure what that
position is. For instance:

   themselves. These assumptions have led to a focus on communications
   security and the development of protocols that place this kind of
   security above all else. Ironically - or coincidentally - as the
   development of these protocols have taken place over the last
   several decades, there has been and continues to be a sharp rise in
   cyber attacks. The Internet threat model in RFC 3552 does not even
   mention that the greatest threat to the Internet is the growing
   scale and variety of cyber attacks against all types of endpoints
   that is resulting in significant data breaches. This now needs to
   change.

First, I'm not sure that I agree that cyber attacks on endpoints are
the greatest threat to the Internet, but even assuming that's so,
what are the implications of that for work in the IETF? It's one thing
to change the words of 3552, but what work specifically would we
do if those words were different.

Second, I think it's quite likely true that the IETF has focused
on communications security, and this document seems to be trying
to argue that that's to the detriment of other kinds of security,
both here and in other places:

   Internet security research and technical development must accept the
   reality of all the security issues in the Internet ecosystem.
   Decisions being made in the name of privacy are sometimes leading to
   larger inadvertent security and privacy losses.

I'd like to try to explore this argument a bit. Specifically, it might
be the case that the IETF has just ignored non-comsec and that if we
had spent more time on it, that would be better. Alternatively, it
could be true that the IETF's focus on comsec has actively harmed
other kinds of security. One gets the sense that this document wants
to argue the latter point, but it doesn't really come out and say it,
let alone substantiate it. That, rather than arguing about the completeness
or appropriateness of RFC 3552, might be a better place to start.

-Ekr

[0] Indeed, work like token binding is arguably a stab at some of this
stuff.

---

From: Bret Jordan <[email-masked]>
Date: Sun, 14 Jul 2019 18:23:56 -0600

Hi Elliot.  

> Is the device in a known good state?

1) Is the content or content provider that the user is going to compromised and trying to attack the endpoint?
2) Is the content provider that the user is going to a stage 2 delivery site?
3) Is the content provider that the user is going to the location for outbound malicious content (data exfiltration, CnC traffic)
4) Is the content provider that the user is going to adversely tracking and monitoring everything the end client does, aka active surveillance versus passive surveillance?
5) Is the remote site that the user did not go to attack the end point. 

All of this in network based / Internet based.  Protocol designs can help make it much more difficult for threat actors, crime syndicates, and intrusion sets from being as effective. 

Thanks,
Bret

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Jul 2019 20:27:29 -0400

>    protocols which minimize the extent of the damage done under these

Hmm... restricting the requirements according to what problems we think we
know how to solve seems to be a bit of a systematic problem in the
industry. I remember when the malware issue hit and the anti-Virus vendors
refused to consider it as their problem because they didn't replicate as
viruses.

> do if those words were different.

I'm not keen on the focus on the end point. It seems like it is brought up
as a trump card to 'prove' that all security efforts are futile and the
criminals must always win. And I don't think it is true its just defeatism.

The reason we need the IETF is that communications protocols are most
useful when everyone uses the same thing so we can talk to each other. So
communications protocols need standards and hence standards for security.

Endpoints don't require standards in quite the same degree. But that
doesn't mean that nothing we do is relevant to endpoints.

For example, forget 95% of trustworthy computing, the main residual
vulnerability of crypto protocols is the risk of private keys being leaked
off the machine. That is an endpoint security control that provides real
leverage for relatively little cost. But it is a mechanism that can only be
used in communication protocols if they are designed with that constraint
in mind.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2019 17:33:32 -0700

On Sun, Jul 14, 2019 at 5:27 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> industry.

Without taking the position on the industry as a whole, the E in IETF
stands for "engineering", so I think trying to solve problems we know how
to solve is prudent. As the list of things we know how to solve increases,
then we ought to attempt to solve those as well.

> criminals must always win.
>

Well, that's certainly not my position.

> doesn't mean that nothing we do is relevant to endpoints.

Nor is this.

-Ekr

---

From: Bret Jordan <[email-masked]>
Date: Sun, 14 Jul 2019 18:45:21 -0600

Hello,

> Hmm... restricting the requirements according to what problems we think we know how to solve seems to be a bit of a systematic problem in the industry. 
> 
> Without taking the position on the industry as a whole, the E in IETF stands for "engineering", so I think trying to solve problems we know how to solve is prudent. As the list of things we know how to solve increases, then we ought to attempt to solve those as well.
> 

Yes, but first we need to make sure we have the open discussions in a congenial manner.  We also need to full understand what is needed by operational security to prevent threat actors and intrusion sets from destroying their networks, users, systems, and data.  

There are many good eco-systems that have very advanced security engineers in them, we should work with them and communicate with them. It would be good for some of us from the IETF to go to these groups and explain what we are working on, why we are working on it, and then ask for feedback from their perspective.  

I believe a document written by the IETF that talks more plainly about the whole security pie, and what parts the IETF is going to try and work on, would be helpful.  We can not boil the ocean.  Further, some parts are better solved outside of the IETF.  We just need to make sure the things we do, do not make other elements of operational security impossible. 

Bret

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 14 Jul 2019 20:48:34 -0400

On Sun, Jul 14, 2019 at 8:34 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Sun, Jul 14, 2019 at 5:27 PM Phillip Hallam-Baker <
> [email-masked]> wrote:
>
>>
>>
>> I'm not keen on the focus on the end point. It seems like it is brought
>> up as a trump card to 'prove' that all security efforts are futile and the

I wasn't suggesting it was. It is just my experience that whenever I
discuss some security protocol development in the wider context there is
always some smart ass who wants to talk about end-point security rather
than the thing the presentation is actually about.

It is like the idea that the hackers have to be smarter than the security
specialists because they can always find a Ford Cortina with its doors
unlocked and the keys in the ignition.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 14 Jul 2019 17:50:10 -0700

Bret,

Thanks for your note.

On Sun, Jul 14, 2019 at 5:45 PM Bret Jordan <[email-masked]> wrote:

>
> I believe a document written by the IETF that talks more plainly about the
> whole security pie, and what parts the IETF is going to try and work on,
> would be helpful.  We can not boil the ocean.  Further, some parts are
> better solved outside of the IETF.  We just need to make sure the things we
> do, do not make other elements of operational security impossible.
>

Much like the original draft, this seems to be implying, but not really
stating something.

If your position is that some protocol engineering that the IETF is doing
is making operational security impossible, it would be useful for you to
argue that directly. As is, it's not really clear how to respond.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Jul 2019 02:51:56 +0100

In addition to Ekr's query (to which I'd also like to see an
answer)...

On 15/07/2019 01:45, Bret Jordan wrote:
> Yes, but first we need to make sure we have the open discussions in a
> congenial manner.  We also need to full understand what is needed by
> operational security to prevent threat actors and intrusion sets from
> destroying their networks, users, systems, and data.
Congeniality is great. Clarity is required.

Your statement is so unclear as to be unwelcome, and the term
unwelcome, as it turns out, seems to be an antonym for congenial. [1]

I'm sorry for being a bit of a smartass there, (and I accept
considering me a smartass would be a fair reaction to the quip
above:-) but ISTM that such absences of clarity too-often
accompany claims that the IETF needs to change rough consensus
positions on comsec and privacy, and I don't think that's
acceptable in what ought be a serious and considered discussion.
(And IMO that criticism applies to the draft mentioned in the
subject line as well.)

A couple of examples of how your statement is unclear:

- "Operational security" could be some unqualified set of people
or it could be a category of for-profit vendors. The relevant
"needs" of those are vastly different IMO. In either case the
term seems pretty badly chosen.
- "Their networks..." could refer to networks (etc.) owned and
operated by some entities or by the customers of some entities.
Again, very different interests are involved.
- Few to zero n/w attacks would be usefully described via the
phrase "destroying...users" - in fact destroy isn't really a
useful verb here generally (as it implies a lack of e.g. backup
and restore functionality). For the few attacks that one might
consider as destroying users (e.g. drones/bombs that kill
humans), I'd argue those ought not be considered in the same
way as attacks that muck about with network settings.
- It makes no sense to to me to talk about "intrusion sets"
"destroying" things.

Cheers,
S.

[1] https://www.merriam-webster.com/dictionary/congenial

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Jul 2019 10:01:40 +0200

Hi Bret,

> 5) Is the remote site that the user did not go to attack the end point.

While we tend to think of endpoints as being equivalent in class, in which case your use of the term "content provider” would be somewhat redundant, from a scaling perspective I am far more concerned about unwatched unmanaged endpoints than I am about content services.  And again, to me it is a matter of what problems I think might be tractable.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Jul 2019 10:11:30 +0200

Hi Eric,

> On 14 Jul 2019, at 23:24, Eric Rescorla <[email-masked]> wrote:
> 
> controls the network.

When you say “network” do you mean the botnet or the wired network connecting devices?  The former is where I and most people would argument most of the trouble stems from: since a great many attacks are coming from batted devices.  I seem to recall that we shut down a botnet some time ago that had more devices than all of the Internet infrastructure at all major carriers combined (it was in the millions).

> Here too, I wouldn't expect 3552 to be deployed

And I would expand that to cover not just DoS, but other forms of attack.

To your point on the E in IETF, I agree that there needs to be clarity on what E is needed. As I wrote elsewhere, I would be happy with quite a bit more R from the sister organization.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jul 2019 04:31:58 -0700

On Mon, Jul 15, 2019 at 1:11 AM Eliot Lear <[email-masked]> 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...

-Ekr

 The former is where I and most people would argument most of the trouble
> stems from: since a great many attacks are coming from batted devices.  I
> seem to recall that we shut down a botnet some time ago that had more
> devices than all of the Internet infrastructure at all major carriers
> combined (it was in the millions).
>

> To your point on the E in IETF, I agree that there needs to be clarity on
> what E is needed. As I wrote elsewhere, I would be happy with quite a bit
> more R from the sister organization.
>
> Eliot
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Jul 2019 14:20:50 +0200

Hi Eric,

> On 15 Jul 2019, at 13:31, Eric Rescorla <[email-masked]> 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.

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 15 Jul 2019 09:07:48 -0400

On Mon, Jul 15, 2019 at 8:20 AM Eliot Lear <[email-masked]> wrote:

> 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

---

From: Bret Jordan <[email-masked]>
Date: Mon, 15 Jul 2019 08:50:18 -0600

Kathleen,

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

This is one of the points I made during my talk at RSA.  These technologies by themselves, are all really great.  The problem comes is when you start using all of them together.  To the naive comment earlier that this is about vendors trying to sell product, no, this is about network and cyber defenders and SoC analysts trying to do their job. There are things like regulatory compliance that organizations and enterprises are required to follow. Some times I feel like we are so worried about one piece of the security pie, that we completely neglect the others. 

Here in the IETF everyone needs to better understand how SoC analysts and network/cyber defenders do their jobs, what they are asked to do, and what tools are available to them. 

Bret

---

From: Bret Jordan <[email-masked]>
Date: Mon, 15 Jul 2019 09:07:19 -0600

Eliot,

However, many here assume that the endpoint can run security software, that security software is available for all endpoints, or that security software can be updated all at once across an organization/enterprise. Other also assume that if you just patched your software, you would be safe.  These assumptions are horribly wrong and goes to show the fundamental lack of understanding.

The reason I called them out the way I did was I was trying to be explicitly clear on where the attack was coming from and what role the endpoint had in that attack. I did not want to assume that everyone understood the attack surface and threat model. 

So a client may initiate the connection to a compromised site or content. This is a very common case for initial infection.  However, once the threat actor is in the network, they often move laterally through the network and compromise machines where the attack is not initiated from the victim endpoint, but rather initiated from a compromised endpoint. So what you can see and do to protect your network changes. 

All of this is pretty basic network/cyber security 101 stuff.  What the IETF needs to know is how SoC analysts need and require sensors on the network, network log data, and DNS data to help identify these attacks and find them. We always had a saying when I was on the other side of the fence, “operating systems and software can always be made to lie, but the network never does..” Network analysis and network forensics is a critical part of the day-to-day analysis in a SoC.  This is often how intrusion sets are detected and threat actors behavior in the network is tracked.  This is not about selling product as some believe. This is about organizations and enterprises protecting their systems, networks, and data.  

Thanks,
Bret

> On Jul 15, 2019, at 2:01 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Bret,
> 
>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jul 2019 08:25:48 -0700

On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan <[email-masked]> wrote:

> This is one of the points I made during my talk at RSA.  These
> technologies by themselves, are all really great.  The problem comes is
> when you start using all of them together.  To the naive comment earlier
> that this is about vendors trying to sell product, no, this is about
> network and cyber defenders and SoC analysts trying to do their job. There
> are things like regulatory compliance that organizations and enterprises
> are required to follow. Some times I feel like we are so worried about one
> piece of the security pie, that we completely neglect the others.
>

Bret,

As I said before, this is extremely general and hard to act on.

What would be most helpful at this point would be for you to describe a few
ways in which you think the IETF should have designed protocols
differently, so that we can discuss them.

-Ekr

> Here in the IETF everyone needs to better understand how SoC analysts and
> network/cyber defenders do their jobs, what they are asked to do, and what
> tools are available to them.
>
> Bret
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Jul 2019 12:03:01 -0400

I am pretty sure this is not security 101 stuff. In fact I am pretty sure
that it will be quite a while before the academy really gets to grips with
this stuff. They don't have the same biases we do but they have different
ones.

For example, the need to patch systems is brought up and this is almost
always seen as a good thing. Not in the process control world it isn't. The
problem of unauthorized updates is a very serious concern for them.

Devices that automatically update themselves are vulnerable to a denial of
service attack by the device provider.

This is not an attack many device providers are worried about because it
isn't an attack that is going to affect them (for a start) and they think
they can trust themselves. Which may well not be true. I have seen a single
employee cause $1 million worth of vandalism after being upset that his
wages were being garnished for alimony. I really doubt that more than 5% of
the companies that make IoT devices have effective controls.

The same is true of devices that depend on a tied service. My Revolv hub is
useless because Google bought the company and shut down the service leaving
me with $2500 worth of dead equipment in my walls.

This is not 101 stuff and in fact I don't think that a single one of the
IoT vendors out there is showing that they understand it. We are still at
what I call the 'narcissistic' phase of the market in which every medium
sized IoT vendor thinks it is all about themselves.

The fact that an IoT device makes the owner dependent on the provider is
totally a security issue. The fact that the device providers don't want to
acknowledge it doesn't make it any less so.

I have spent well over $25,000 on IoT devices in the past few years. Of
these, I cannot think of a single one that I can give an unqualified
recommendation for. And there are security issues with every single one of
them.

On Mon, Jul 15, 2019 at 11:07 AM Bret Jordan <[email-masked]> wrote:

> Eliot,
>
> However, many here assume that the endpoint can run security software,
> that security software is available for all endpoints, or that security
> software can be updated all at once across an organization/enterprise.
> Other also assume that if you just patched your software, you would be
> safe.  These assumptions are horribly wrong and goes to show the
> fundamental lack of understanding.
>
> The reason I called them out the way I did was I was trying to be
> explicitly clear on where the attack was coming from and what role the
> endpoint had in that attack. I did not want to assume that everyone
> understood the attack surface and threat model.
>
> So a client may initiate the connection to a compromised site or content.
> This is a very common case for initial infection.  However, once the threat
> actor is in the network, they often move laterally through the network and
> compromise machines where the attack is not initiated from the victim
> endpoint, but rather initiated from a compromised endpoint. So what you can
> see and do to protect your network changes.
>
> All of this is pretty basic network/cyber security 101 stuff.  What the
> IETF needs to know is how SoC analysts need and require sensors on the
> network, network log data, and DNS data to help identify these attacks and
> find them. We always had a saying when I was on the other side of the
> fence, “operating systems and software can always be made to lie, but the
> network never does..” Network analysis and network forensics is a critical
> part of the day-to-day analysis in a SoC.  This is often how intrusion sets
> are detected and threat actors behavior in the network is tracked.  This is
> not about selling product as some believe. This is about organizations and
> enterprises protecting their systems, networks, and data.
>
> Thanks,
> Bret
> 1) Is the content or content provider that the user is going to
> compromised and trying to attack the endpoint?
> 3) Is the content provider that the user is going to the location for
> outbound malicious content (data exfiltration, CnC traffic)
> 4) Is the content provider that the user is going to adversely tracking
> and monitoring everything the end client does, aka active surveillance
> versus passive surveillance?
> While we tend to think of endpoints as being equivalent in class, in which
> case your use of the term "content provider” would be somewhat redundant,
> from a scaling perspective I am far more concerned about unwatched
> unmanaged endpoints than I am about content services.  And again, to me it
> is a matter of what problems I think might be tractable.
>
> Eliot
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Jul 2019 18:16:29 +0200

Phil,

> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> I am pretty sure this is not security 101 stuff. In fact I am pretty sure that it will be quite a while before the academy really gets to grips with this stuff. They don't have the same biases we do but they have different ones.
> 
> For example, the need to patch systems is brought up and this is almost always seen as a good thing. Not in the process control world it isn't. The problem of unauthorized updates is a very serious concern for them.

I think I agree with your thesis statement but not your supporting statement above.  There are a great many “best practices” that are coming out, and they all to a one usually involve usernames and passwords for a good number of devices that might not require either.  And in fact, the idea of a password for machine controlled devices is Just Bad.

Patches themselves from the vendors are absolutely required to be available, but the timing of their installation needs to be left to customers based on when – if at all – those devices can allow for a window where the device may miss a beat.  But even in these cases, process control systems need in service upgrade mechanisms, because the reality is that the bugs will be there.

> 
> Devices that automatically update themselves are vulnerable to a denial of service attack by the device provider.
> 
> This is not an attack many device providers are worried about because it isn't an attack that is going to affect them (for a start) and they think they can trust themselves. Which may well not be true. I have seen a single employee cause $1 million worth of vandalism after being upset that his wages were being garnished for alimony. I really doubt that more than 5% of the companies that make IoT devices have effective controls.

Ok, but that is no reason to not have automated updates available.  That is more of a reason to have strong audit processes in place.

> 
> The same is true of devices that depend on a tied service. My Revolv hub is useless because Google bought the company and shut down the service leaving me with $2500 worth of dead equipment in my walls.
> 
> This is not 101 stuff and in fact I don't think that a single one of the IoT vendors out there is showing that they understand it. We are still at what I call the 'narcissistic' phase of the market in which every medium sized IoT vendor thinks it is all about themselves.
> 
> 
> The fact that an IoT device makes the owner dependent on the provider is totally a security issue. The fact that the device providers don't want to acknowledge it doesn't make it any less so.

I agree that this is indeed a security issue, but that doesn’t mean that it’s the wrong way to go.  There are other factors to take into consideration, not the least of which is cogs and e-Waste associated with unnecessarily shipping extra horse power to 20 million endpoints when a little elastic processing in the cloud will do.

Eliot

---

From: Bret Jordan <[email-masked]>
Date: Mon, 15 Jul 2019 10:24:05 -0600

My key points were due to the responses I hear form some in the IETF, specifically

“If you just patched your endpoints there would be no issue”
“All endpoints can easily run security software”

Thanks,
Bret

> On Jul 15, 2019, at 10:16 AM, Eliot Lear <[email-masked]> wrote:
> 
> Phil,
> 
> 
> 
>> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Bret Jordan <[email-masked]>
Date: Mon, 15 Jul 2019 11:02:12 -0600

Ekr,

It is not so much that it was designed wrong, but that when critical functionality was removed, there was no alternative method added to support critical use cases. So one can argue that some decisions were done from a myopic point of view, without realizing the problems they will create. 

There are many examples, but let us just take two for right now.  I am sure I will enrage people to no end and cause an uproar, but so be it. 

Hiding the Server Certificate
This is a wonderful thing for open internet sessions as it help prevent passive analysis of users traffic and where a user is going. So from that side, it is great. However, from the managed network stand point it is terrible. This feature/data is a critical element used in managed networks and is critical for ensuring regulatory compliance. The problem is not so much that the WG decided to hide it. The problem is the WG did not and has not yet provided an alternative solution to fill in the missing gap. So either the WG does not understand the operational security requirements around it, or they are just choosing to ignore them.

DNS over HTTPS and DANE
This is also a really neat idea. However, when you layer this with DANE+DNS_SEC you get to a point where installed trust anchors no longer become effective.  Further, managed networks really rely on DNS data for both first line defense and retrospective analysis of threat actor / CnC behavior.  So DNS over HTTPs by itself is not a bad thing.  But the way it is being implemented in products and the possibility of using it with other solutions like DANE can make operational security significantly more challenging if not impossible.  Threat Actors are already starting to use DoH to launch attacks, since it provides a way for them to get around some security controls. So it becomes critical that for things like DoH that products provide a way for it to be turned off, or for managed networks to specify their own DoH servers.  Further, managed networks need to start looking at locating their internal DNS servers on the WAN side of their proxies / firewalls so that they can create islands of trust and rewrite the DNS_SEC on the fly if they need too.  But all of this should be called out and where possible, we should provide ways for management networks to still do what they need. 

So I would like the security considerations to be updated to help ensure that we ask the questions, like “what is this going to do to operational security?”, “how is this going to impact incident response and network forensics?”.  I want to also be super clear that I am not against these technologies by themselves. But we need to ask these hard questions and provide solutions that can still enable managed networks to protect themselves.   Thinking that everything can and should be done on the endpoint is just outright naive. 

Thanks,
Bret

> On Jul 15, 2019, at 9:25 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> 
> On Mon, Jul 15, 2019 at 7:50 AM Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> Kathleen,
> 
> 
> What would be most helpful at this point would be for you to describe a few ways in which you think the IETF should have designed protocols differently, so that we can discuss them.
> 
> -Ekr
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Jul 2019 14:07:48 -0400

On Mon, Jul 15, 2019 at 12:16 PM Eliot Lear <[email-masked]> wrote:

> I think I agree with your thesis statement but not your supporting
> statement above.  There are a great many “best practices” that are coming
> out, and they all to a one usually involve usernames and passwords for a
> good number of devices that might not require either.  And in fact, the
> idea of a password for machine controlled devices is Just Bad.
>
> Patches themselves from the vendors are absolutely *required* to be
> available, but the timing of their installation needs to be left to
> customers based on when – if at all – those devices can allow for a window
> where the device may miss a beat.  But even in these cases, process control
> systems need in service upgrade mechanisms, because the reality is that the
> bugs will be there.
>

No, there is no absolute security requirement here. There are two concerns
that are potentially in conflict

1) The vendor may have introduced a security vulnerability
2) The vendor may use an update to reduce or remove functionality.

Again, I have $2,000 worth of Nest equipment in the house. Google recently
announced that they are discontinuing support for their previous
interconnectivity support that my current home configuration uses. My hub
provider may or may not support the new scheme. What this means is that my
device vendor has abused its update privilege to restrict my device
functionality for its own profit.

That is a security concern that affects my wallet and it matters much more
to me than the possibility that the vendor might want to distribute a
legitimate update patch to address their potential incompetence.

Setting up the first requirement that affects a manufacturer interest as
absolute and unchallengable is wrong. There are two requirements here.
patches are not a security requirement, they are a security control.

> Ok, but that is no reason to not have automated updates available.  That
> is more of a reason to have strong audit processes in place.
>

If the vendors were capable of doing strong audit controls, they would be
capable of writing code that can't be compromised by a buffer overrun
exploit.

I see this demand for patching as being an anti-pattern that is being
promoted by the folk who think that dumping linux plus some Python on an
IoT device and shipping it is an acceptable IoT approach. It isn't. You
cannot secure a platform with 15 million lines of code. IoT devices should
not be built round kernels designed to support a general purpose computing
model. The attack surface is ridiculous. There is no way that is going to
be patchable.

Using a dedicated IoT kernel like .NET Core running on the bare metal with
as little intermediation  as possible is the way forward.

> I agree that this is indeed a security issue, but that doesn’t mean that
> it’s the wrong way to go.  There are other factors to take into
> consideration, not the least of which is cogs and e-Waste associated with
> unnecessarily shipping extra horse power to 20 million endpoints when a
> little elastic processing in the cloud will do.
>

Cloud computing is good. But it doesn't have to be the cloud provided by
the manufacturer.

Devices should connect to the cloud I provide which may be off site or may
be onsite. A Raspberry Pi W for $5 has more computing power than the
machine I used when I was designing the Web specs at CERN. We used the same
class of machine to control experiments with 550 tons of depleted uranium.

Moving the control points off site is a lazy model. The smart home should
be capable of working even if the Internet service is down. I have at least
two dozen machines in the house capable of delivering a gigaflop. So I
really should not need to move anything out of my house to process.

The podcast series I am currently editing is called 'Should this be
Internet' and it is about IoT devices. I will be giving something of a
preview a week on Thursday. Spoiler alert: the answer on all the segments
so far is 'no'. And I am the person who has been spending a small fortune
buying all this stuff.

My big fear here is that we are trading on the enthusiasm of the early
adopter market and there is a real risk that if we don't start building IoT
devices that aren't more trouble than they are worth before that enthusiasm
is spent, we will end up with an IoT winter.

Remember that (almost) everything we are currently seeing in 'AI' is stuff
that was basically developed in the 1980s. They set expectations that
couldn't be met by the technology of the day. By the later 1990s, the
machines were plenty powerful enough but the AI winter didn't see a thaw
for another decade.