Subject: [Model-t] Reviewing documents: draft-lazanski-{users-threat-model-t, protocol-sec-design-model-t}

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Aug 2020 23:20:52 +0300

Dominique, all,

Trying to (re-)read documents before the call today. Thought I’d post some observations from the ones that I’ve read:

Users-threat-model-t:
================

The document has:

- general motivation
- overview of recent, highly publicized data breach incidents
- couple of examples of botnet cases
- some examples
- sections on impacts, updating the model, and way forward

Good motivation. I thought that the data breach section was quite good and convincing. 

The botnet and emerging threats parts seemed a bit less fully covered. The sections on impacts, updates, and way forward were a bit short, too. 

Wondering if it would be useful to focus the draft a bit more narrowly (as with other drafts, including mine). Don’t handle everything, but what you focus on, cover well.

Some formatting issues in section 7.

Protocol-sec-design-model-t:
======================

The document has:

- a classification of issues to endpoint compromise, network, compromise, DoS, phishing, malware, insider threats, traffic hijacking, web-based attacks, and malware-free attacks
- a classification of impacts to data exfiltration, etc.
- classification of defensive measures
- a collection of design guidelines to deal with the issues, impacts, and defensive measures

I liked the use of attack examples to illustrate a problem and then explaining a design guideline that is needed to counter this issue.

Not sure how in-depth the design guidelines are though. And there’s a lot of material. Some comments:

Section 2.2 recommends cryptographic confidentiality protection. This seems to be already largely the case, but I suspect that NotPetay type attacks are still a problem.

Also, this seemed unclear:

   Finally, if an attacker engages in re-routing, re-ordering,
   replaying, delaying or dropping data on the network, which is
   arguably less well-handled by existing Internet transport protocols,
   then protocol design considerations would include development of
   strong sender authentication, integrity checks over whole sessions
   not just individual packets, replay detection, and out-of-order
   packet detection.

Replay detection, data stream integrity, authentication, etc. are already common features in today's Internet communications.

Section 2.3 says this about DoS defenses:

   Protocol designers
   should be aware of potential issues that help DDoS attacks, such as:
   CoAP flooding, protocols that permit mass unscheduled deliveries,
   provision of the ability for an attacker to mask e.g. IP addresses,
   provision of the ability to amplify, a lack of sender
   authentication, a long time open request and an inability to filter
   at scale.[5] Assessment of protocol for abuse and DoS amplification
   should be a part of the security assessment during the design
   iteration process.

I think that these largely already are concerns that we do worry about in  the IETF, and do check protocols for these. Maybe in some case we don't put enough weight on avoiding e.g. amplication, but it certainly already is a well-covered concern.

Section 2.7 says this about hijack attack defenses:

   Protocol design considerations
   should include authentication and handshake management when sending
   and accepting traffic. This will be an ongoing and iterative process
   so the protocol design must take into consideration the management
   of this repetitive process.  Protocol design should also take into
   account how to prevent DNS cache poisoning and route table
   manipulation and communicate that such a process occurred.

The problem is that we either have tools to fight this (e.g., DNSSEC) or don’t fully (e.g., routing) but it has been an uphill battle to make progress in these areas with deployment, perhaps incentives for deployment have not been good enough. It is unclear to me what the fix/direction is, actually, but maybe others have ideas.

Note that we do have authentication of at least one party and handshaking for most Internet connections, but while that helps authenticate a connection, it doesn't help much if routing fabric
doesn't get your packets to the right place. No improper connections will be made, but no successful communications can be established either.

I wonder if it is possible to provide a single document that discusses all advice. It seems like we should select between pretty high level guidance (e.g., the couple of things we could say about reducing problems with compromised parties in the suggested 3552 additions) or focused on a particular more detailed topic, such as DoS defences or routing security.