On 13/09/2011, at 5:12, Marsh Ray <ma...@extendedsubset.com> wrote:
> It never was, and yet, it is asked to do that routinely today. > > This is where threat modeling falls flat. > > The more generally useful a communications facility that you develop, the > less knowledge and control the engineer has about the conditions under which > it will be used. > > SSL/TLS is very general and very useful. We can place very little restriction > on how it is deployed. To be fair, I think this part has been done very well by the designers. I get the feeling that the original designers really didn't understand anything at the business and architecture side, so backed off and decided to secure a low level toolbox as best as possible. In this case TCP. I guess we've all been there, I know I have. If they had then said SSL (inc. PKI) secures TCP against a broad range of attacks, then all would have been consistent. But, as soon as we get to business, these claims loose foundation. Can it be used to secure credit cards? Websites? Love-chat? Dissident planning? The answer is ... Dunno! Seriously, we have no clue. But we still get app-level architects taking the Pareto-secure result of SSL and implying it on their business: > It will be used wherever it "works" and "feels secure". More and more > firewalls seem to be proxying port 80 and passing port 443. So it will > continue to be used a lot. > > Few app layer protocol designers will say "this really wasn't part of the > SSL/TLS threat model, we should use something else". Most will say "this is > readily available and is used by critical infrastructure and transactions of > far greater value than ours". > > It needs to be as secure as possible, but I freely admit that I don't know > what that means. It's a good start :) I once tried to answer that with the concept of Pareto-secure, but I'm not sure the concept is self-referential as yet. Iang _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
