* Aaron Zauner <[email protected]> [04/04/2016 17:24:37] wrote: > As for authentication/TOFU: I see no better proposal than TACK > around. HPKP was an utter failure [0] and I fear that, for the > very same reasons, SMTP-STS might not see a lot of deployment nor > use in single-domain-setups. And there're quite a few around. > While it's important to secure the majority of mail traffic > between large providers - they're already doing well - we should > not forget that there's still a lot of self-hosted MXs on the > Internet. I could imagine an updated (e.g. using EdDSA over ECDSA > etc) version of TACK fitted to SMTP. One of the original authors > might be interested in working on that he told me earlier this > year, unfortunately I did not have any time to pursue this idea > further.
Could work like that: the MTA announces an additional extension (e.g. NOSTRIP), once the other side sees that, it requires that the MTA support STARTTLS and the TLS TACK extension [0]. An in-band upgrade is performed and TACK/policy information retrieved and stored. These pins can be used on follow-up connections, and the way TACK handles key-rollover it's very unlikely that operators have to take a lot of care regarding their pins (this is why HPKP fails and isn't widely deployed). For implementors this doesn't change much either; as with the original SMTP-STS proposal the MTA needs to be aware of policy information. This information is now provided by TACK. TACK is a TLS extension, so functionality only needs to be provided from the library (TLS stack - there's already TACK code available for e.g. OpenSSL). The beauty really is TACK's pin lifecycle and rollover. It being an extension, it's also rather easy to deploy (eg. an admin would just need to upgrade their system TLS stack to a current release), and deployment is usually the biggest barrier, especially in small/single-domain setups as we've seen from our scans. Reporting could be handeled entirely seperate or as a SHOULD. Aaron [0] http://tack.io/draft.html
signature.asc
Description: Digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
