Correcting numerous typos and adding more points... > Agreed. Closing holes is real security. > > I went one step further than your point, to assert that making artifical > limitations on programming APIs would actually DECREASE security, and this > is due to Coase's Theorem (nature will route around any artificial barrier > that increases opportunity costs): > > http://www.ietf.org/mail-archive/web/http-state/current/msg00932.html > > I forgot to mention Coase's Theorem in the above post, so thanks for > raising the issue again. I think there are far too many cases where we chase the shadows, instead of real holes and solutions. And this is destroying the freedom/opportunities on the internet in my opinion (will end up with the big server farm companies being the only ones whitelisted and rest of us in slavery). For example, the whole concept of firewalling everything and then whitelisting the internet. That isn't security, it is just a way of letting only the viruses come in and not the useful programs. When programs have to written with STUN tunneling like a virus, the internet is fundamentally broken by Almost-Better-Than-Nothing security models. So now 99% of the possible internet connections are unavailable unless one writes their program like a virus: http://www.ietf.org/mail-archive/web/hybi/current/msg03549.html http://www.ietf.org/mail-archive/web/hybi/current/msg03231.html IPv4 said that NATs should not be doing what they are doing. I don't think IPv6 will fix the problem, because it is not a problem just of available of IP addresses, but also of wrong security models. Instead if we have full disk and OS encryption and protection, then the firewall model is unnecessary: https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c41 I can advance that to CSRF attacks too, where I can not find any logic in categorizing a payload attack as CSRF when it was injected some other way (the real hole is the injection point), not via violation of Same Origin policy (SOP). This misunderstanding leads to overzealous SOP that is unnecessary and also further whitelists and destroys the internet model of mesh networking: http://www.ietf.org/mail-archive/web/hybi/current/msg03334.html https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c14 >> A colleague and I produced this initial draft as an alternative to the >> traditional cookie approach to try to secure session state: >> http://tools.ietf.org/html/draft-salgueiro-secure-state-management > > > I did not yet have time to read that. I will comment on your summary > below. > > >> This was just our "straw man" proposal, but we think it is one worth >> considering. Ideally, the server would assign an encryption key via >> HTTPS. >> This would be combined with a nonce produced at the client when the >> session >> information is encrypted. This would result in changing encrypted data >> and >> the nonce value is monotonically increasing so the server can avoid >> replay >> attacks. > > > Wow, I really like the idea of the encryption key for encrypting the > cookies stored on the client disk. That way the user of the client > browser does not have to establish a master password. I meant the encryption key comes from the server via HTTPS as you wrote. > And each site's > cookies are encrypted on the client's disk with a different encryption > key. What would be a perfect solution afaics now. Is that what you mean? "That would be a perfect..." > As for the nonce concept for session keys: > > 1) I think we keep that concept orthogonal to the encryption of cookies on > the client disk. It could be in the same draft, but a different section. > > 2) Unfortunately I don't think that nonce against reply attack is > security. Because if intruder gets the nonce before it has been used, that > is still a hole. I believe in closing holes instead. It we properly guard > the session id, it won't matter if it is a nonce of a session persistent "nonce OR a session persistant value" > value. Nonces are good idea for other reasons too (e.g. recognizing a > stale request), and I think the application should be free to use them, > but I don't think they should be mandated for security reasons. I for one > don't use them in my design and wouldn't want to be forced to use them.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.