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

[Bret Jordan <[e-mail]>]

I fully agree that there will need to be some foundational documents written to help the IETF as a whole come up to speed.  

We are basically in the same boat with cyber in the IETF as we are with crypto. If you do not know what key material, or a Nonce, or how asymmetric differs from symmetric algorithms, or how the discrete logarithm problem compares to prime factorization, you will be lost.  So the crypto side of the IETF uses a lot of jargon, as well.  But it is domain specific vernacular. This cyber side also has a lost of very well known and understood terms.  I am sure ENISA, NIST, and even the ITU have great resources.  ISC^2 and SANS also have a lot of material about this space. 

What we are trying to do now is help the IETF realize that it is more than just communication security and information security.  The market just happens to call this bigger umbrella "cyber security".  But I know many here do not like that term, even if the industry does use it.  Trying to break the problem down to just one of the sub parts is where we fall over and where we get in trouble. 

  
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 12:37 PM, Ted Lemon <[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>>> https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>
>>