comp.lang.ada
 help / color / mirror / Atom feed
From: Olivier Henley <olivier.henley@gmail.com>
Subject: Re: Ada for the TLS/SSL problem?
Date: Wed, 16 Mar 2016 12:57:55 -0700 (PDT)
Date: 2016-03-16T12:57:55-07:00	[thread overview]
Message-ID: <dfe29c95-c70c-4a4f-b91a-1f7010279527@googlegroups.com> (raw)
In-Reply-To: <ncc3o0$1ftn$1@gioia.aioe.org>

On Wednesday, March 16, 2016 at 1:05:09 PM UTC-4, Dmitry A. Kazakov wrote:
> On 2016-03-16 13:09, Peter Brooks wrote:
> 
> > My feeling is that we'd need a general, configurable, security
> > layer.  This can be proved to work by implementing TLS.
> 
> Well from my POV the idea of a layer as known in SSL/TLS is a 
> non-starter. It is broken per design because it cannot provide 
> reasonable QoS, short latency required for automation and control 
> applications.
> 
> The basic requirement is that encryption and signing may not coalesce 
> transport packets. Ideally it should work on the packet level with 
> packets of any length. I understand that this would impose difficult 
> problems but otherwise it would be unusable outside lousy web applications.
> 
> It is OK to implement TLS as-is, nobody would object that. But something 
> better must be really better.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Not sure but I think its related ... http://www.tcpcrypt.org/:

How Tcpcrypt is different

Some of us already encrypt some network traffic using SSL (e.g., HTTPS) or VPNs. Those solutions are inadequate for ubiquitous encryption. For example, almost all solutions rely on a PKI to stop man-in-the-middle attacks, which for ubiquitous deployment would mean that all Internet users would have to get verified by a CA like Verisign and have to spend money to buy a certificate. Tcpcrypt abstracts away authentication, allowing any mechanism to be used, whether PKI, passwords, or something else.

Next, Tcpcrypt can be incrementally deployed: it has a mechanism for probing support and can gracefully fall back to TCP. It also requires no configuration (try that with a VPN!) and has no NAT issues. Finally, Tcpcrypt has very high performance (up to 25x faster than SSL), making it feasible for high volume servers to enable encryption on all connections. While weaker by default, Tcpcrypt is more realistic for universal deployment.

We can easily make the bar much higher for attackers, so let's do it. How much longer are we going to stay clear-text by default?

  parent reply	other threads:[~2016-03-16 19:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-15 18:46 Ada for the TLS/SSL problem? Peter Brooks
2016-03-15 19:00 ` Shark8
2016-03-15 19:10   ` Peter Brooks
2016-03-15 19:04 ` Shark8
2016-03-15 20:47 ` Florian Weimer
2016-03-16  8:14   ` Dmitry A. Kazakov
2016-03-16 17:42     ` Florian Weimer
2016-03-16 18:25       ` Dmitry A. Kazakov
2016-03-16 22:18         ` Florian Weimer
2016-03-17  8:14           ` Dmitry A. Kazakov
2016-03-15 21:02 ` Paul Rubin
2016-03-16  4:08   ` Peter Brooks
2016-03-16  6:13     ` Paul Rubin
2016-03-16 12:09       ` Peter Brooks
2016-03-16 17:04         ` Dmitry A. Kazakov
2016-03-16 18:31           ` Peter Brooks
2016-03-16 20:28             ` Dmitry A. Kazakov
2016-03-16 19:57           ` Olivier Henley [this message]
2016-03-16  8:42 ` Jacob Sparre Andersen
2016-03-16  8:46   ` Dmitry A. Kazakov
2016-03-16 10:52   ` G.B.
2016-03-16 15:27     ` G.B.
2016-03-16 12:14   ` Peter Brooks
2016-03-16 12:17     ` Bob Butler
2016-04-26 10:42 ` Peter Brooks
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox