Subj : BINKP over TLS
To   : Oli
From : Alexey Fayans
Date : Tue Dec 17 2019 01:26 pm

Hello Oli!

On Tue, 17 Dec 2019 at 08:33 +0100, you wrote to me:

 AF>> It's not about believing. You can read on wikipedia for example
 AF>> about MitM and STARTTLS. MitM can fool client into thinking
 AF>> STARTTLS is not supported. Mitigation is requiring encryption on
 AF>> client side. As simple as that.
 Ol> If you already know that the other side supports encryption and you
 Ol> want to enforce it, you don't need STARTTLS.

STARTTLS is needed to run TLS on the same port, and I already explained why it 
is essential to run it on the same port.

 AI>>> I don't think the binkd developers are going to bring STARTTLS
 AI>>> to the table but we need to hear from them.
 AF>> Exactly.
 Ol> The had plenty of time. binkp is not only used by binkd. Direct TLS
 Ol> works today with binkd with some helper software.

This implementation is a proof of concept, but obviously will not be adopted by 
most sysops. And what is the point in security when no-one uses it?

 AF>> Synhcronet is not the only software out there. And manual
 AF>> configuration is not even an option. Globally, (1) a new nodelist
 AF>> flag is required to indicate support if binkps and its port;
 Ol> Now we need to stop introducing new nodelist flags?

I didn't say that.

 AF>> (2) binkps must be supported on DNS level as well, i.e.
 AF>> _binkps._tcp SRV records;
 Ol> not need if you have a nodelist flag. nodelist flag not needed if
 Ol> there is a _binkps._tcp record.

That is not true. Some mailers do not support nodelists and rely on DNS. For 
example, binkd.

 AF>> (3) nodelist parsers must be updated to understand new flag;
 Ol> Yeah, you should use a nodelist parser that gets updated occasionally.

Sure. But if something can be done without requiring updates to software, it 
should be done this way. Less requirements means better adoption.

 AF>>  (4) additional configuration must be introduced in mailers to
 AF>> support binkps, and for binkd it may be an issue since node
 AF>> records were not designed for multiple protocols based on
 AF>> different ports.
 Ol> So software has to be updated in both cases, especially the mailer.

Yes, the difference is how big are the updates and how much software will need 
to be updated.

 Ol> You still can use unencrypted or CRYPTed sessions, if your software
 Ol> doesn't has support for any new encryption scheme.

Of course. And I am sure that most sysops will not move to dedicated TLS port 
because of the complexity. Why designing something that will not be adopted - 
that is the big question.

 AF>> With STARTTLS none of this is a problem. Additional configuration
 AF>> flag to require TLS connection is easy to implement, nodelist
 AF>> flag is optional and may be used to tell client to require TLS
 AF>> when connecting to supporting node, and additional DNS SRV
 AF>> records are not needed as well.
 Ol> Do we have a proposal for binkp STARTTLS that doesn't leak unencrypted
 Ol> meta-data?

Client can initiate STARTTLS right away. Server can wait for STARTTLS handshake 
a few seconds before starting unencrypted session (this will probably introduce 
a few seconds delay with older mailers). Just an example. Probably developers 
can think of a better way.


.... 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)

.