Re: [Smart] CLESS Reset - Open Call Thursday 14th of May at 6pm CET / 9am PST

[Mallory Knodel <[e-mail]>]

Hi Arnaud,

I reviewed this draft and have some feedback. Document that I reviewed:

https://datatracker.ietf.org/doc/draft-taddei-smart-cless-introduction 
<https://datatracker.ietf.org/doc/draft-taddei-smart-cless-introduction/>


My review could be taken as a privacy review and I used the HRPC 
guidelines document as well. So, on to the review.


The “perfect endpoint security solution” described on page 14 does 
contain some privacy/surveillance issues. Below are the relevant system 
features with my comments:

1.1 “monitor any behavior on the endpoint, including inbound and 
outbound network traffic, learn and identify normal behavior and detect 
and block malicious actions, even if the attack is misusing legitimate 
clean system tools or hiding with a rootkit,” doesn't acknowledge that 
there maybe conditions under which such monitoring becomes invasive for 
users.

1.2 “allow the endpoint to communicate with the other endpoints in the 
local network and globally, to learn from ’the crowd’ and dynamically 
update rules based on its findings,” might define some bar for the type 
of data collected and shared locally as well as limits on what would be 
done with that data.

1.3 “offers a reliable logging that can’t be tampered with, even in the 
event of system compromise,” doesn't define tampering, which in my view 
is too narrow anyway unless we can consider unauthorized copying and use 
to be tampering. Logging minimums and maximums are really important for 
user privacy, even if that isn't PII data.

2.1 When discussing the limits of endpoint security systems, it states 
“The other hidden dimension here is the economical aspect. Many 
manufacturer are reluctant to invest in IoT device security, because it 
can significantly increases [sic] the cost of their solution and there 
is the perception that they will lose market shares, as customers are 
not prepared to pay the extra cost for added security”. This is 
certainly a valid concern; however, it demonstrates the lack of 
responsibility held by companies who develop such products. I would 
actually place this exact wording into a paragraph about the limitations 
of non-endpoint-only security models insofar as they creates an easy out 
for profit seeking companies to avoid end-point-security. And on the 
other hand there is strong evidence that data privacy is a desired 
feature, as well as a minimum standard.

2.2 “A recent survey found that fewer than 10% of consumer IoT companies 
follow vulnerability disclosure guidelines at all, which is regarded as 
a basic first step in patching vulnerabilities (see [IOTPATCHING]). This 
indicates that many IoT devices do not have a defined update process or 
may not even create patches for most of the vulnerabilities,” which in 
turn indicates that this is a problem irregardless of endpoint-only or 
other security model, does it not? (In fact I think there's a huge 
amount of work that's needed to untangle limitations with endpoint-only 
only or any security model limitation, in general, which of course there 
are several!

2.3 In general I think this boils down to inconveniences and costs of 
the endpoint-only security model to companies, which isn't really the 
same as a limitation of the technology itself against what it aims to 
do. I would simply recommend removing these considerations completely.

3. The “perfect solution” portion of this proposal introduces a number 
of potential human rights issues, that RFC 8280 (also 
draft-irtf-hrpc-guidelines) were helpful in seeking out:
3.1 Censorship resistance: The draft discusses network filtering 
techniques to prevent malware, spam, etc to fully legitimate end, 
however it's important to treat and acknowledge the risk of 
over-blocking allowable user communications.
3.2 Pseudonymity: Related to data privacy shared previously, how must 
alternatives to endpoint-only security models compensate for the 
anonymisation of data provided by endpoint security?
3.3 Confidentiality: There is a clear trade off for the confidentiality 
between two endpoints for the purposes of local network security. 
Comments to this end have been pointed out and shared above, but, again, 
I see no serious treatment of attempting to make up for this fact.

4.1 Suggest changes to whitelist/blacklist along the lines of 
https://tools.ietf.org/html/draft-knodel-terminology

5. My strongest plea is if this draft is intended for the IRTF, that 
some reference to actual research on what is being, or can be, done in 
practice to secure networks despite the prevalence of endpoint-only 
security. For example if a company determines significant need it could 
fingerprint TLS, such as 
https://blogs.cisco.com/security/tls-fingerprinting-in-the-real-world. 
I'm interested in seeing research in SMART that accepts the state of the 
art as a given and advances forward-looking solutions. This draft feels 
like it's trying to roll back the tide.

I suggest both a privacy and a human rights considerations section if 
this draft moves forward.

-Mallory

On 5/5/20 8:22 AM, Arnaud.Taddei.IETF wrote:
> Dear all, after a too long pause I restarted to work on "CLESS"
> https://datatracker.ietf.org/doc/draft-taddei-smart-cless-introduction/ 
> <https://datatracker.ietf.org/doc/draft-taddei-smart-cless-introduction/>
>
> Given a number of contextual changes I would like to check with the 
> community on the direction to take with this work and would like to 
> get feedback.
>
> Call details:
> Time: Thursday 14th of May at 6pm CET / 9am PST
> Duration: 1h
> Method: WebEx meeting 927523370
> https://broadcom.webex.com/meet/arnaud.taddei 
> <https://broadcom.webex.com/meet/arnaud.taddei>
>
> If you want to send me an email at [e-mail] 
> <mailto:[e-mail]> I can send you a calendar invite
>
> Thank you in advance and stay safe
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
>
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780