Hi, Viktor Dukhovni wrote: > Well somebody publishes MX and/or A records for the domain so it can > get mail.
Sure, there's no way around *this* step. > MTA-to-MTA SMTP (relay) establishes connections to wherever the MX records > point. The MX records are in DNS. Therefore, if active attacks are in > scope, and DNS is not protected from active attack, you cannot protect > of MTA-to-MTA SMTP from active attack. None of the proposals you suggest > both scale and work if DNS is subject to MITM. Yes but verification will fail if you MITM DNS and redirect to an previously unpinned server. > If you have an architecture that somehow avoids critical reliance on DNS > security, and works even for infrequent or first-time communication, you > need to explain how it does in some detail. I've not seen anything that > matches that description. This is certainly true as I haven't worked out (or even started) with an appropriate I-D or anything really besides the very informal e-mail with which this thread started out. And this is the first feedback I've gotten since. Due to research work I haven't found time to write anything up yet that goes beyond this. By IETF Note Well this still serves as a contribution to IETF discourse. The smtp-sts I-D on GitHub is still lacking a lot of details, so I can just make assumptions. Currently, with the policy is authenticated via WebPKI instead of TLSA you'll need complete out-of-band verification for MTA to MTA transactions. I've come up with the same idea in January and after some discussion with other security people quickly abandoned this idea and never wrote about it to IETF. A Postmaster operating the MX needs to be in control of the issued WebPKI certificate (which means: ideally the certificate supports Certificate Transparency and HPKP headers are set on the Web-server). This might be impractical for many operators: Currently more than 60% of SMTP MTAs do _not_ have signed certificates, far less even provide valid CN or SAN X.509 information. TACK does not require certificates to be CA-signed, this is completely optional. TACK also makes revocation and key-rollover a bit easier than this proposal. TACK also makes life-cycle management and clustered set-ups a bit easier as multiple MXs could be pinned to the same TSK. Again; that might work fine for the companies the authors of smtp-sts work for and their large hosting infrastructures, it will not work for the common SMTP instance somewhere below a desk in an office. I don't see that this proposal would be widely deployed by mail operators. The proposal also means significant change to already deployed codebases for mail transfer. And quite a bit of extra effort on the operator side as I've already noted. We need something that'll do with `sudo apt-get update`, ideally. Otherwise I fear we won't see much deployment. > As for postmasters v.s provider hosted domains, I might note that udmedia.de > have published TLSA records for the MX hosts of ~30,000 (perhaps more now) > domains, without any need for the domain owner to take explicit action for > that to happen. There also a few thousand such domains hosted by each of > nederhost.net and transip.nl. The provider case is actually the easy one, > if the provider is willing to take the appropriate steps. If not, switch > to a better provider. Thanks for the numbers. Switching providers for operators might not as easy as you think it is due to contractual agreements or pre-existing dependencies on other support infrastructure (for example DNS or even the smtp-sts supporting WebPKI infrastructure which might not be hosted on the same machine). I'll think more about this - need to get some sleep. Thanks for you feedback, Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
