RE: [Nea] heads-up on distsec
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Nea] heads-up on distsec
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:pekkas at netcore.fi]
Sent: Sunday, March 19, 2006 6:14 AM
To: nea at ietf.org
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.
--
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
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.