= Сообщение: 6459 из 7128 ====================================== FTSC_PUBLIC = От : Rob Swindell 1:103/705 24 Mar 22 14:30:00 Кому : James Coyle 24 Mar 22 14:30:00 Тема : Re: Re^8: Directly include binary data in messages FGHI : area://FTSC_PUBLIC?msgid=31923.ftsc_pub@1:103/705+26a2958b На : area://FTSC_PUBLIC?msgid=1:129/215+96319cbd = Кодировка сообщения определена как: CP437 ================================== ============================================================================== Re: Re: Re^8: Directly include binary data in messages By: James Coyle to Tim Schattkowsky on Mon Mar 21 2022 03:16 pm
> TS> So is there now any implementation BinkP implementation using STARTTLS > TS> and what are the details? > > TS> BTW: RFC8314 suggests already in the introduction that for email, > TS> implicit TLS should be preferred over STARTTLS :) > > Yes there is. I did a STARTTLS-enabled BINKP a few years ago and its > currently available in Mystic that you can download here: > > http://www.mysticbbs.com/downloads/prealpha/ > > I have sent the documentation over to Rob for implementation and/or feedback > but I didn't want to post it here yet to avoid trolling. I'd be happy to > e-mail it along to you as well if you're interested in supporting it!
I haven't made the time to experiment with STARTTLS support in Synchronet's BinkIT yet. I will and get back to you.
> TS> BTW: RFC8314 suggests already in the introduction that for email, > TS> implicit TLS should be preferred over STARTTLS :) > > Implicit would be great (and Mystic actually implements both implicit and > opportunistic TLS v1.2 with BINKP), but the problem with implicit is > two-fold: > > 1) For mass adoption, having a self-upgrading connection is probably the > most realistic to be used. In other words, existing setups wouldn't have to > be changed in order to support it. No additional nodelist flags, etc, would > be needed. It wouldn't break any existing systems while those that support > it would simply just work. > > 2) The IANA has denied officially giving us a port for BINKPS, which means > that implicit SSL can never be an official standard unless they were to some > how be persuaded to change their mind. > > Mostly due to #2 it seems to me like the best approach for us to move > forward would be to adopt Mystic's opportunistic TLS or some variation of > it. Or to support both, ideally?
Yeah, there's really no downside to supporting both, unless the STARTTLS implementation is somehow determined to be less secure. But we'll work to make sure that's not the case. -- digital man (rob)
