Subject: [Nea] heads-up on distsec

From: Pekka Savola <[email-masked]>
Date: Sun, 19 Mar 2006 16:13:55 +0200 (EET)

Hi,

I just read the NEA problem statement and it looked rather sensible. 
What you didn't explain very extensively is your threat model.  You 
can be sure this will come up in the BoF from someone..

You already raise NEA Client self-integrity as an issue in Section 
9.3.  But is NEA approach good enough here because the first thing a 
next-generation worm/virus/malware will do is trick the NEA client 
using one of various techniques, therefore making the real posture 
undetectable?

You may not be aware of the "distsec" effort (the lastest draft 
rewrite is draft-kaeo-distsec-framework-00.txt), which describes a 
superset problem.  I'd recommend taking a look for ideas how to refine 
the problem statement, threat model and assumptions.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Thomas Hardjono" <[email-masked]>
Date: Sun, 19 Mar 2006 08:36:44 -0800

Pekka,

Yes, Section 9.3 is trying to convey the awareness of the problem for future
discussion (and perhaps for the requirements document).

My personal opinion on this matter is that something trustworthy needs to
attest to the goodness (trustworthiness) the NEA Client code/binary. This
in-turn requires something that malicious code cannot modify (namely trusted
hardware).

/thomas/

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Sunday, March 19, 2006 6:14 AM
To: [email-masked]
Subject: [Nea] heads-up on distsec

Hi,

I just read the NEA problem statement and it looked rather sensible. 
What you didn't explain very extensively is your threat model.  You can be
sure this will come up in the BoF from someone..

You already raise NEA Client self-integrity as an issue in Section 9.3.  But
is NEA approach good enough here because the first thing a next-generation
worm/virus/malware will do is trick the NEA client using one of various
techniques, therefore making the real posture undetectable?

You may not be aware of the "distsec" effort (the lastest draft rewrite is
draft-kaeo-distsec-framework-00.txt), which describes a superset problem.
I'd recommend taking a look for ideas how to refine the problem statement,
threat model and assumptions.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 19 Mar 2006 18:58:34 +0200 (EET)

Hi,

> in-turn requires something that malicious code cannot modify (namely trusted

Is it enough to have trusted NEA client code?  The client will collect 
information from the programs, file systems, and/or the kernel.  So, 
each of those (except maybe the programs themselves) would need to be 
"trusted".

I'm personally a bit skeptical how we could get there, given that 
kernels will always have bugs, etc.

Of course, security mechanisms don't necessarily need to be perfect; 
getting e.g., 95% assurance might be enough, given that's acceptable 
for your threat model..

(That was one of the reasons why distsec was refined to also look at 
minimizing the effect and maximizing the detection of a security 
breach that's bound to happen sooner or later.)

---

From: "Thomas Hardjono" <[email-masked]>
Date: Sun, 19 Mar 2006 17:35:22 -0800

Understood, Pekka.  The BOF/WG would have to decide if these issues (such
that mentioned in Section 9.3) and their solution would be in-scope for NEA.

I think it is useful for NEA to be aware of the spectrum of issues
surrounding (a) end-point trust and integrity, and (b) mechanisms to report
(a).  This was one of the purposes of Section 9.  In this way, NEA can focus
on a clear subset of issues out of the entire spectrum.

Regards.

/thomas/

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Sunday, March 19, 2006 8:59 AM
To: Thomas Hardjono
Cc: 'Hardjono, Thomas'; [email-masked]
Subject: RE: [Nea] heads-up on distsec

Hi,

On Sun, 19 Mar 2006, Thomas Hardjono wrote:
> My personal opinion on this matter is that something trustworthy needs 
> to attest to the goodness (trustworthiness) the NEA Client 
> code/binary. This in-turn requires something that malicious code 
> cannot modify (namely trusted hardware).

Is it enough to have trusted NEA client code?  The client will collect
information from the programs, file systems, and/or the kernel.  So, each of
those (except maybe the programs themselves) would need to be "trusted".

I'm personally a bit skeptical how we could get there, given that kernels
will always have bugs, etc.

Of course, security mechanisms don't necessarily need to be perfect; getting
e.g., 95% assurance might be enough, given that's acceptable for your threat
model..

(That was one of the reasons why distsec was refined to also look at
minimizing the effect and maximizing the detection of a security breach
that's bound to happen sooner or later.)