On Thu, Jan 30, 2014 at 12:04 PM, Orit Levin (LCA) <[email protected]>wrote:
> Good points. > In the meanwhile, we invite you to join the effort at UTA > http://datatracker.ietf.org/wg/uta/charter/ . > Orit. > Using TLS in Applications is useful work but not quite what I was suggesting. I think the security profiles need to be more than 'best practices'. They need to be a set of specific practices that meet specific security requirements. There are some areas where a security profile activity might lead to standards work. For example I am pretty sure that some of our application protocols cannot be deployed securely and standards compliant. There is also a question of audience participation. The audience for these specs would be security practitioners, not protocol designers. Most of the application security holes being created right now involve tools that I would simply never consider using because they are a security nightmare. It took quite a lot of us quite some time to understand the significance of HTTP injection attacks because we would never consider hooking up a scripting language in that way in the first place. So the community that needs to buy in here is the OWASP/BlackHat community rather the protocol design community. I don't really want to set up yet another standards organization and these may not be standards in the usual sense. It certainly seems useful to re-use IETF or W3C to publish the profiles. But there may be an advantage to some sort of political separation. I can point to quite a few IETF specs that have been broken as far as practical deployment goes and efforts to fix the problem have been thwarted through committee inertia. What looks good to a standards committee can be absolutely cretinous in actual deployment. To take a non IETF example, can anyone fill in the blank here? if (x != x) { <what code goes here?> } We can thank an IEEE committee for that particular facepalm. Some idiots worrying about mathematical models and laws developed a standard that creates ugly holes in the laws of every programming language built on that spec. The laws of occam originally included IF (x = x) <proc> |= <proc> and IF (x != x) <proc> |= SKIP. But those aren't true and someone with their pants in a bunch on a standards group is to blame. So if we have a group look at mail security profiles I would really like the political setup to allow that group to publish a report stating that X, Y and Z are defects in the SMTP, TLS or whatever protocols and for that to publish without someone on the IESG being able to veto it because they want to protect their baby. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
