Subj : BINKP over TLS
To   : Rob Swindell
From : Alexey Fayans
Date : Sat Dec 21 2019 06:01 am

Hello Rob!

On Fri, 20 Dec 2019 at 11:55 -0800, you wrote to me:

 >> So far you didn't provide a single fact proving that good STARTTLS
 >> implementation is less secure than TLS on a dedicated port.
 RS> Opportunistic TLS gives both the client and the server (or a MitM) the
 RS> ability to "opt-out" of using TLS.

Depends on implementation. Protocol (binkp) may require to drop connection if 
TLS negotiation fails with a node that supports TLS according to nodelist.

 RS> With an Implicit TLS session, no such option is availble; the entire
 RS> TCP session is secure, or it doesn't exist.

And how is it more secure than above?

 >> Use of self-signed certs without a well-defined and implemented
 >> mandatory mechanism to verify these certs (either trusted CA or any
 >> other similar way) just turns whole security talk into a joke.
 >> Seriously.
 RS> A less funny joke than Binkd's CRYPT option. Seriously.

Sure, but did I ever speak about it?

 >>  >> Why not? It is perfectly mitigated and I explained that a few
 >> times
 >>  >> already. You gotta stop looking back at old SMTP implementation
 >>  >> that wasn't designed against active MitM attacks in the first
 >>  >> place.
 >>  RS> I look at all the applications of Opportunistic TLS and
 >> they're all
 >>  RS> less secure than Implicit TLS.
 >>
 >> Examples?

 RS> NNTP, FTP, IRC.

Sure, all very old designs without security in mind. Also, all of these are 
just services while FIDONET is an ecosystem and has a nodelist where TLS 
support can be indicated. That makes a perfect platform for a truly secure 
STARTTLS implementation.

 >> Maybe you are just looking at bad / not suitable implementations.
 >> Not all implementations are focused on MitM protection and that is
 >> fine, similar to use of self-signed certs just to make it a bit
 >> harder to sniff the traffic.
 RS> Security is a moving target. If you're going to implement something,
 RS> as I have with binkps, you shoot for the state of the art, today's
 RS> best practices, not yesterday's.

Like I said earlier, there is no universal standard for everything. When you 
design something, you gotta be smart and understand well what you are doing and 
why.

 RS> STARTTLS is yesterday's solution

Nope, only a few not very well designed implementations are `yesterdays 
solution`.


 RS> It would be silly to
 RS> implement STARTTLS in a newly-defined TCP applictaion protocol today.

Nope, it will be silly to design a protocol that has no future.


.... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
 * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)

.