Re: [Model-t] [e-mail] list description

[Ted Lemon <[e-mail]>]

Bret, I appreciate that this is a special area of technical expertise and that it has a domain-specific vocabulary. That is what the word “jargon” means. 

The reason I raised this concern is not that I can’t go out and learn this jargon. It’s that if the goal of this effort is to help the IETF to do a better job of reasoning about threats, the IETF has to be able to understand the output. 

There is already great work going on in this space amongst the experts. If this is to just be another such effort, I don’t think it will accomplish your stated goals.  So I’m being deliberately pedantic here because I would like to see the output of this effort actually change how the IETF reasons about threats. That’s going to require some foundational documents. The fact that you didn’t point me at an RFC or draft to answer my question tells me that I’m not wrong to be concerned. 

Sent from my iPhone

> On Aug 3, 2019, at 1:39 PM, Bret Jordan <[e-mail]> wrote:
> 
> Ted,
> 
> This is not jargon, this is the language that is used in this space. If we are going to write a document or come up with text to help improve a document that deals with this domain, then we should probably know and understand the domain. Attacks against network connected devices (endpoints, network equipment, IoT devices, etc) are all in scope.  So when we work on designing solutions for interconnected systems, we need to understand this space.  Designing technologies without taking this space into consideration is very problematic.  
> 
> We have many in this group that work in this space and have very detailed knowledge of it.  If you have specific questions, I am sure many of us would be willing to help fill in the gaps.  
> 
> IMO, the key to our work is to help improve the IETF’s understanding of risks, threat actor TTPs, attack surface, etc.  This space has evolved a lot recently, and has definitely changed since 3552 was first written.  Further, given the upcoming market shift to 5G enabled devices and its changing attack surface, this work is prudent at this time.  Gone are the days of “Escargot Model” (a term I started using back in the late 80s / early 90s) of security. 
> 
> 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 Aug 3, 2019, at 11:12 AM, Ted Lemon <[e-mail]> wrote:
>> 
>> Yes. It would also be good to avoid domain-specific jargon. Presumably the goal here is to provide something of value to the whole community, not something that only people who are familiar with a very specific vernacular can use. 
>> 
>> Of course, I might be mistaken about the intended scope of this work, so if this sounds wrong it would be good to get consensus on that. 
>> 
>> Sent from my iPhone
>> 
>>>> On Aug 3, 2019, at 12:52 PM, Jim Fenton <[e-mail]> wrote:
>>>> 
>>>> On 8/2/19 9:24 PM, Bret Jordan wrote:
>>>> 
>>>> To borrow your words…  “If we are going to take security seriously”…
>>>> we need to understand and document the full attack surface.  So let
>>>> us start listing them out.  Here are four.
>>>> 
>>>> 
>>>> Attack: Active remote attack
>>>> Exposure: Full compromise of system and data
>>>> Client Knowledge: Potential indicators may be visible
>>>> Protection Possibilities: Deploy both client and network level protections
>>>> Headwinds: Client based protections are usually inadequate
>>>> Severity: High
>>>> Kill-Chain Phase: Lateral Movement
>>> 
>>> [etc.]
>>> 
>>> Perhaps we need to decide what we consider a threat model to be. I see
>>> Bret's list as a collection of specific attacks (tactics), while I
>>> consider a threat model to be at a higher level than that, e.g., whether
>>> nation-states, or supply chain threats, should be part of that model.
>>> 
>>> When I was working on the draft that became RFC 4686 (DKIM Threat
>>> Analysis), Russ Housley gave me some very good coaching about how to
>>> structure that. He suggested that it should describe:
>>> 
>>> - The nature and location of the bad actors
>>> - What the bad actors' capabilities are
>>> - What they intend to accomplish via their attacks
>>> 
>>> How do we want to define threat model?
>>> 
>>> -Jim
>>> 
>>> 
>>> 
>>> -- 
>>> Model-t mailing list
>>> [e-mail]
>>> https://www.iab.org/mailman/listinfo/model-t
>