On Sep 19, 2017, at 2:22 PM, Lyndon Nerenberg <lyndon@xxxxxxxxxx> wrote: > But that basically declares everything that uses a STARTTLS-like machanism 'insecure'. Does that mean they're flagging IMAP, POP, and SMTP/Submission as insecure, too? That's correct. Anything that uses STARTTLS and doesn't fail when STARTTLS doesn't get a TLS connection with a cert that validates is not secure. > If DNSSEC says the A record for foo.example.net is valid, and the FTP TLS negotiation gives me a cert with a CN=foo.example.net, I'd say that's more than hand waving. Yes, but the RFC doesn't say to do that. It says you *could* do that, but doesn't even say so in sufficient detail to implement. If it's not a requirement that causes interop to fail when it's not followed, it's not secure enough to trust. This is a bit nitpicky—the operational environment in which the RFC was approved was quite a bit different than the present. The point is simply that if we want to ensure that people are downloading untainted versions of RFCs, we can't use FTP. I believe that at least the Chrome dev team is officially moving in this direction. Dunno if Chrome implements TLS for FTP, though. If it did, then it could do as you say and trust the destination based on a PKI match; if this were true of all browsers, then I would say that we should set up our FTP server to do that. :)