Subj : BINKP over TLS
To   : Alexey Fayans
From : Oli
Date : Tue Dec 17 2019 08:33 am

 AF>>> No it doesn't. MitM attack can only fool client into thinking
 AF>>> that TLS is not supported. But you can require TLS on a client
 AF>>> side and it will just disconnect, no harm done.
 AI>> I believe it does.

 AF> It's not about believing. You can read on wikipedia for example about
 AF> MitM and STARTTLS. MitM can fool client into thinking STARTTLS is not
 AF> supported. Mitigation is requiring encryption on client side. As
 AF> simple as that.

If you already know that the other side supports encryption and you want to 
enforce it, you don't need STARTTLS.

 AI>> I don't think the binkd developers are going to bring STARTTLS to
 AI>> the table but we need to hear from them.

 AF> Exactly.

The had plenty of time. binkp is not only used by binkd. Direct TLS works today 
with binkd with some helper software.

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

Now we need to stop introducing new nodelist flags?

 AF> (2) binkps must be supported on DNS level as well, i.e. _binkps._tcp
 AF> SRV records;

not need if you have a nodelist flag. nodelist flag not needed if there is a 
_binkps._tcp record.

 AF> (3) nodelist parsers must be updated to understand new flag;

Yeah, you should use a nodelist parser that gets updated occasionally.

 AF>  (4) additional configuration must be introduced in mailers to support
 AF> binkps, and for binkd it may be an issue since node records were not
 AF> designed for multiple protocols based on different ports.

So software has to be updated in both cases, especially the mailer. You still 
can use unencrypted or CRYPTed sessions, if your software doesn't has support 
for any new encryption scheme.

 AF> With STARTTLS none of this is a problem. Additional configuration flag
 AF> to require TLS connection is easy to implement, nodelist flag is
 AF> optional and may be used to tell client to require TLS when connecting
 AF> to supporting node, and additional DNS SRV records are not needed as
 AF> well.

Do we have a proposal for binkp STARTTLS that doesn't leak unencrypted 
meta-data?

 
* Origin: kakistocracy (2:280/464.47)

.