On 15/04/2014 21:07 pm, d...@deadhat.com wrote: >> http://clearcryptocode.org/tls/ >> >> Probably not going to happen, but it's nice to dream... >> > > It is one of my long term, implausible goals to replace TLS with a > collection of independent app to app function-targeted security protocols > that are individually simple enough to understand and implement cleanly. I > will certainly fail.
It's certainly possible. It's more or less what I do. Adoption and generating the commercial feedback cycle to finance the programmers is the problem, not the technology. > E.G. > For paying with a credit card.. A secure credit card payment protocol > > For authenticating a web site and producing keys to bind .. A web page > authentication protocol. > > For remotely logging into a shell producing keys to bind .. A secure shell > login protocol. > > There are many more possibilities. > > Today, SSL and TLS with all that entails (ASN.1, X.509, PKCS, TCP/IP etc.) > is the hammer and any securable thing is the nail. But it's really a > client-server session privacy and integrity protocol with issues. It isn't > designed to protect my banking transactions, just the traffic over which I > communicate my transaction intent. If I had a secure bank transaction > protocol independent of TLS, heartbleed wouldn't matter. > > A classic mismatch between TLS and its primary use securing web traffic is > the failure of a virtual server to be able to produce the right cert for > the right virtual web site. The cert is really identifying the TLS > termination point which may be a web server, rather than a web site, of > which the server may be serving many. That's one reason why a web-site > security protocol would be more effective than TLS plumbed under HTTP. > > TLS does need nuking so we can replace it with simpler things. The > sentiment isn't wrong, it's just hard to pull off. For amusement, someone pointed me at the tcpcrypt group on the IETF sites. So I spend some days reading and got dragged into conversation. It's weird, I don't think I could design a more flawed process if I tried. But the good thing is that while the IETF working groups are focussed on breaking TCP, others are working to replace it. The question is, how to best replace it? Recent discussions indicate that there are many ways to do this, and the space defies easy cataloging. Which means that the formal, committee, standards, consensus group approaches won't work. How then to replace? And indeed is it a replacement or a bypass, an evolution or a revolution? _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
