Hello Alan!

On Tue, 17 Dec 2019 at 03:11 -0800, you wrote to me:

 AI> I'm not going anywhere until I believe, in something. I don't mind
 AI> having my beliefs proven to be worthless, in fact I appreciate it if
 AI> they are in fact worthless.

Well, like I suggested earlier, you can read about STARTTLS on wikipedia, where
you will find confirmation of my words and more examples of weakness
mitigation, including DNS based (DANE) and MTA-STS (lHSTS for SMTP).

 AI>>> That's why STARTTLS has been depricated.
 AF>> It's not deprecated globally. Deprecation is only _proposed_ for
 AF>> SMTP and other mail protocols and there are reasons for that, but
 AF>> that doesn't mean it is deprecated for everything else.
 AI> I have only ever used STARTTLS with smtp. If STARTTLS is proposed to
 AI> be depricated for smtp I propose we depricate it here too.

There is absolutely no point in deprecating it. There are pros and cons
everywhere. Weak place of STARTTLS is STRIPTLS attack. In FIDONET we have a
nodelist to indicate support of TLS by a node, which mitigates this.

 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.
 AI> I don't think STARTTLS is going to fly. I really have no strong
 AI> feelings for or against STARTTLS, I just don't think that is what
 AI> anyone wants today.

I don't see any reasons why not. Any security method can be implemented in a
good or a bad way. If method weakness is taken into account when protocol is
designed, there is no problem with it. STARTTLS failed for SMTP because it was
not implemented in a secure way.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707