Re: TLS break

2009-11-10 Thread Tom Weinstein

Perry E. Metzger wrote:

I'll point out that in the midst of several current discussions, the
news of the TLS protocol bug has gone almost unnoticed, even though it
is by far the most interesting news of recent months.


Perhaps because there have been so many false alarms over the years. 
Usually when I hear about an SSL MITM attack, it's really a browser UI 
spoofing attack with a bogus cert.


This is the first attack against TLS that I consider to be the real 
deal. To really fix it is going to require a change to all affected 
clients and servers. Fortunately, Eric Rescorla has a protocol extension 
that appears to do the job.


--
Give a man a fire and he's warm for a day, but set | Tom Weinstein
him on fire and he's warm for the rest of his life.| twei...@pacbell.net

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: SSL stops credit card sniffing is a correlation/causality myth

2005-06-02 Thread Tom Weinstein

Ian G wrote:


But don't get me wrong - I am not saying that we should
carry out a world wide pogrom on SSL/PKI.  What I am
saying is that once we accept that listening right now
is not an issue - not a threat that is being actively
dedended against - this allows us the wiggle room to
deploy that infrastructure against phishing.

Does that make sense?
 

No, not really. Until you can show me an Internet Draft for a solution 
to phishing that requires that we give up SSL, I don't see any reason to 
do so. As a consumer, I'd be very reluctant to give up SSL for credit 
card transactions because I use it all the time and it makes me feel safer.



What matters is now:  what attacks are happening
now.  Does phishing exist, and does it take a lot of
money?  What can we do about it?
 

If you don't know what we can do about phishing, why do you think that 
getting rid of SSL is a necessary first step? You seem to be putting the 
cart in front of the horse.


--
Give a man a fire and he's warm for a day, but set | Tom Weinstein
him on fire and he's warm for the rest of his life.| [EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: SSL, client certs, and MITM (was WYTM?)

2003-10-22 Thread Tom Weinstein
Ian Grigg wrote:

Tom Weinstein wrote:
 

In threat analysis, you have to base your assessment on capabilities,
not intentions. If an attack is possible, then you must guard against
it. It doesn't matter if you think potential attackers don't intend to
attack you that way, because you really don't know if that's true or not
and they can always change their minds without telling you.
   

In threat analysis, you base your assessment on
economics of what is reasonable to protect.  It
is perfectly valid to decline to protect against
a possible threat, if the cost thereof is too high,
as compared against the benefits.
This is the reason that we cannot simply accept
the possible as a basis for engineering of any
form, let alone cryptography.  And this is the
reason why, if we can't measure it, then we are
probably justified in assuming it's not a threat
we need to worry about.
The economic view might be a reasonable view for an end-user to take, 
but it's not a good one for a protocol designer. The protocol designer 
doesn't have an economic model for how end-users will end up using the 
protocol, and it's dangerous to assume one. This is especially true for 
a protocol like TLS that is intended to be used as a general solution 
for a wide range of applications.

In some ways, I think this is something that all standards face. For any 
particular application, the standard might be less cost effective than a 
custom solution. But it's much cheaper to design something once that 
works for everyone off the shelf than it would be to custom design a new 
one each and every time.

--
Give a man a fire and he's warm for a day, but set   | Tom Weinstein
him on fire and he's warm for the rest of his life.  | [EMAIL PROTECTED] 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]