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.
Netscape caved, for their commercial interests. There was also the CA
business model. User's own interests took last place.
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.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
