Hi, > On 05 Apr 2016, at 01:44, Binu Ramakrishnan <[email protected]> wrote: > > Aaron, > > Whether we use Git to distribute policies or use CT append logs, we still > need to pull policies using HTTPS (or something similar). From that > perspective, STS's webpki model is not different. If you are talking about > TACK, based on my understanding it is not suitable for SMTP MTAs. The > fundamental issue is that a secure in-band policy distribution is difficult > in such environments because of MX indirection.
Could you go a bit into what you consider "mx indirection" and where you see problems there? e.g. a specific problem statement. I'm not sure I follow. > > > The main properties that make building on TACK interesting for me are: > > - Lifecycle-management / Key-rollover (no accidental lock-out as you may > > get with HPKP) > This may not even a differentiator. I don't follow? > > - No need for CA-signed certificates (fits well into the SMTPS domain) > How the trust is establised without DNSSEC or PKIX? It's a TOFU model. So you establish trust on first use / flight. From thereon you have pins. See above w.r.t. roll-over. > > > - Ease of deployment > I would have agreed with "ease of deployment" if openssl changes serve as a > drop-in replacement that magically enforce policy, but that is not the case. > Just updating openssl alone is not going enable this feature. In addition to > TLS library upgrade, we need to make changes to MTA to make it work with > STARTTLS flow. On top of that TACK draft also mentions about fetching pins > from a 3rd party, even that also may require HTTPS. Yes, but the same is very much true with STS as well, or did I misunderstand something entirely? Ideally it might be as easy as an `sudo apt-get upgrade openssl exim -y`. If the upstream distribution packages well and provides proper tooling, this can be *very* smooth. If there's zero tooling it's a burden for admins, but that's the same issue with any proposal of that kind. TACK only mentions as a note that pins _could_ be also fetched from servers. This is probably not something I'd incorporate. This is entirely optional and I'm not sure it's implemented anywhere. In the UTA meeting today something similar was mentioned for pre-fetching policies with SMTP-STS: cronjobs and fetch from HTTPS. > > - Ease of maintenance (a good, automated implementation may do everything > > on it's own) > STS provides lot of flexibility with deployment; for instance, we can deploy > separate outbound MTAs for valid STS domains without even touching outbound > MTAs at all (STS check happens before queuing it to outbound MTAs). I already mentioned that small-mail shops probably won't go through all of the difficulties of deploying a proper SMTP-STS setup. Added to that, most dont have DNSSEC. >HTTPS is current medium of policy distribution, but it can be replaced with >anything better in the future. Right, so why not ponder over better solutions? Someone might come up with something good after all! Thanks, Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
