From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.140.39.229 with SMTP id v92mr4272343qgv.25.1458158276096; Wed, 16 Mar 2016 12:57:56 -0700 (PDT) X-Received: by 10.182.80.74 with SMTP id p10mr95412obx.8.1458158276057; Wed, 16 Mar 2016 12:57:56 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!y89no7723937qge.0!news-out.google.com!k1ni524igd.0!nntp.google.com!nt3no2245565igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 16 Mar 2016 12:57:55 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.98.56.20; posting-account=MRPdDAoAAADUJmZVjnYaoafXFMadSeY1 NNTP-Posting-Host: 216.98.56.20 References: <5011d79c-aaad-464e-a68e-c31a2738a820@googlegroups.com> <87a8lzcv5a.fsf@jester.gateway.pace.com> <87wpp3ar1l.fsf@jester.gateway.pace.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada for the TLS/SSL problem? From: Olivier Henley Injection-Date: Wed, 16 Mar 2016 19:57:56 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29810 Date: 2016-03-16T12:57:55-07:00 List-Id: 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: >=20 > > My feeling is that we'd need a general, configurable, security > > layer. This can be proved to work by implementing TLS. >=20 > Well from my POV the idea of a layer as known in SSL/TLS is a=20 > non-starter. It is broken per design because it cannot provide=20 > reasonable QoS, short latency required for automation and control=20 > applications. >=20 > The basic requirement is that encryption and signing may not coalesce=20 > transport packets. Ideally it should work on the packet level with=20 > packets of any length. I understand that this would impose difficult=20 > problems but otherwise it would be unusable outside lousy web application= s. >=20 > It is OK to implement TLS as-is, nobody would object that. But something= =20 > better must be really better. >=20 > --=20 > 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, whi= ch 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 cert= ificate. 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 probin= g support and can gracefully fall back to TCP. It also requires no configur= ation (try that with a VPN!) and has no NAT issues. Finally, Tcpcrypt has v= ery high performance (up to 25x faster than SSL), making it feasible for hi= gh 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 m= uch longer are we going to stay clear-text by default?