> From: Damien Saucez <[email protected]>
> it is simply that I think the security in LISP is not "just enough" but
> "almost just enough". Saying just enough gives me the impression that
> the question is done, solved. But I think we have not explored yet all
> what we could have in term of security for LISP.
> ...
> My academic blood tells me that we should look at everything and try to
> find magical solutions to protect everything. On the other hand, the
> operations show that in security the best is really the enemy of the
> good. So we have to find a trade-off between best and good.
I think I get what you're talking about here, and yes, that section of the
'Introduction' document is not quite as well worded as it could be. I will
see if I can clarify it; slightly wordsmith that section to make it clearer
that LISP's basic security philosophy is not just 'we'll deal with it later'.
Your comment about the balance between security and practicality, etc does
bring up a topic, though.
As it happens, I spent a couple of months about a year back thinking about
how secure DDT, and as a part of that, worked out an overall security
philosophy for LISP.
(Not a 'security structure', that would include things like 'we use private
keys to secure the bindings'. By 'security philosophy', I meant something
much more general - along the lines of your 'balance between security and
practicality' point.)
As part of the DDT security effort, I produced a very rough draft about DDT
security; however, the document talked about more than securing DDT, it
started by talking about an overall philosophy of security in LISP - it tried
to develop one, explaining and justifying why that one in particular was
chosen, and only _then_ applying that to the particular task of securing DDT.
(Briefly, it attempted to provide a path to very hard 'long term' security,
while at the same time not adding a great deal of 'up front' burden. In other
words, we should indeed to have a path, with packet hooks, etc in place for
industrial grade security, when we need it - but for the moment to leave it
out of implementations/deployment, until it is needed.)
I did use some of the text/concepts in this draft in the 'Security' section
of the 'Perspective' document, in the discussion of security in LISP.
However it would probably be useful to assemble the 'LISP security
philosophy' material from that rough DDT-Security draft into a note to the
WG, which can then decide if that security philosophy sounds
reasonable/desirable. (I will do that shortly.) That way, I can make sure
that people buy into this concept of LISP's security philosophy is! :-)
I think you'll find that what I meant by 'just in time' security is something
different, and with better long-range adaptability (although, as I mentioned,
it could probably be worded better).
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
