Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?

[Tony Arcieri]

On Tue, May 13, 2014 at 4:23 PM, Phillip Hallam-Baker hal...@gmail.comwrote:

 In general any proposal of the form 'lets replace X with something 10%
 'better'' is a losing proposition. Particularly when we are talking
 about systems where network effects dominate such as protocols, APIs
 and keyboard layouts[1].


Does that mean that JSON was more than 10% better than XML, or REST more
than 10% better than SOAP?

That's not to say that enterprise users don't still make extensive use of
the, for lack of a better term, crappier technologies, but for the rest of
us, we hopefully don't have those monstrosities in our daily lives anymore.

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?

[Tony Arcieri]

On Thu, May 15, 2014 at 1:26 PM, Phillip Hallam-Baker hal...@gmail.comwrote:

 JSON is a lot more than 10% better than ASN.1 or XML because both of the
 latter are bjorked. XML prefixes are insane


And TLS isn't? ;)

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?

[ianG]

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