On 1/10/11 22:11 PM, William Allen Simpson wrote:
I started reading this thread, and then left it alone, and am catching
up.
It's hard to know where to start, so changing the subject a little.
:)
On 9/20/11 12:51 PM, ianG wrote:
On 20/09/11 01:53 AM, Andy Steingruebl wrote:
SSH doesn't solve phishing either. Is it a total failure also? I
don't think so. SSL is used for a lot more than HTTPS. Any proposal
to "fix" it *must* take that into account. - Andy
Irrelevant, because SSH at the architectural level and SSH at the
protocol level are aligned and in balance. There is no discord
because SSH was never really taken out of its intended design
framework. That's arguably because the designer wasn't facing the
political forces of the times, which the designers of SSL drowned in.
For whatever reasons, we can skip that and look at the results: SSH
was pretty much always used in accordance with its original
design-assumptions, whereas SSL was pretty much never used
in accordance with its original design-assumptions.
Actually, SSH faced a lot of the same political pressures as SSL. SSH
didn't cave! Instead, they carefully did all the work by non-US persons
outside the US -- even though that meant some foreign developers of
OpenSSH had to drive across the US border into Canada.
Meanwhile, back when Netscape was located near the Stanford campus (an
easy walk from the computing center), Paul Mockapetris got me to visit.
I sat down with Taher Elgamal and others, explaining what we were doing
with Photuris.
To the best of my memory, we thought it would be better to:
1) Authenticate the list of supported methods/transforms. We did that in
Photuris to avoid MITM attackers choosing the lowest common denominator.
And not only the parameters, but the length fields of the parameters,
too.
Karn had insisted on cheap Photuris renegotiation from the start, and
that
requires protection against substitution.
2) Hide the certificates/users. We called that "party privacy
protection". We used the initial D-H exchange to create a temporary
stream key, and "masked" the data with the stream (simply an MD5 hash).
3) Require Perfect Forward Secrecy. We'd not managed to get IPsec to do
that. It was a big argument at the time. Even today, not all TLS suites
provide PFS.
4) Authenticate outside of encryption, so we could quickly and cheaply
check before doing a more computationally intensive decryption. We
managed to force that into IPsec, and hoped to get Netscape to do the
same for SSL (now TLS). IIRC, that's since been proven to be more
secure,
but we didn't know it at the time. We were mostly interested in
practicality.
So how was it that Netscape SSL had exactly the same faults as IPsec,
ISAKMP, Oakley, IKE? Political pressure! Somebody really REALLY
wanted to
be able track users and intercept/substitute....
Do I have proof? No, it's merely circumstantial. Also, my multi-year
FBI
personal investigation over PPP CHAP was coincidental, too.
Proof is hard. But we might see it in the future. Not now, but in a
few years.
Whoever that somebody is, they did too good a job. And now they get to
pay the cost. It isn't as if they can cherry-pick the consequences,
because the net was cast too wide: the whole infrastructure is
institutionally weak, and if we triangulate the spots that should have
been strong but are weak, they all seem to point one location.
So now we have the cyber-war scenario. One side spikes a nuclear plant,
the other side punches a hole in "trust" infra. Tit for tat, bring it on!
I suspect if it does take off -- tit for tat in cyber warfare -- there
will be some smarter people who will realise they stupidly fired the
first shot. And now they can't stop the 100 shots...
Not a few people in there will be examining the causes, and realise that
they set themselves up for a fall.
Ho to reverse this? I suspect the only way is for somebody to come
clean and tell people what they did.
Otherwise, all the believers out there will ... carry on, keeping our
infrastructure insecure.
Netscape caved, for their commercial interests. There was also the CA
business model. User's own interests took last place.
https://financialcryptography.com/mt/archives/000609.html I think it
was inevitable.
So, arguing about ease of use is a waste of time, as long as the easy to
use protocol was designed to be broken. It really is time to start over.
Well, yes and no, WYTM? The thing is, "somebody" doesn't really matter
to us. Arguably, ComodoHacker doesn't really matter as much as all the
press makes out. And he's fixable.
What matters is phishing and breaches. And the former is impacted by
SSL. If we could get more SSL it would improve things. The reason we
can't is because the UI is so horrible that people prefer to avoid it.
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
