Hi, > On 05 Apr 2016, at 11:16, Daniel Margolis <[email protected]> wrote: > 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. > > To slightly paraphrase Binu's reply, I think one of the (if not the) key > challenges with SMTP STS is allowing the email domain to specify a routing > policy (and maybe also a security policy, as discussed with Chris up-thread) > regardless of whether it's also the email hosting domain. > > I'm not clear on how TACK can be used here.
TACK isn't the right place to distribute information from. It's a TLS extension, it should be terse. My original idea was to use a SMTP extension along with required TACK-like authentication. The extension could send arbitrary information. As mentioned earlier, I'm not sure what the best way is to integrate this with STS. > > One idea on how to use a CT-style append-only log is that you could use the > log itself as the source of policies, and the log server can sort of do > whatever it wants to for the log inclusion criteria (e.g. with CT the > inclusion criteria are "must be an EV cert", but that's very arbitrary; a > different log could include any policy served over validated HTTPS for any > domain, or you could have a log that includes policies seen by EFF's outbound > MTA--since the log is observable and append-only, it still feels a lot safer > to me to do this than to use Github for policy distribution). Yes, I totally agree there. git was brought up in a discussion, we're not currently implementing anything in that direction. When we come back to this we'll see what's available from UTA etc. for us to use. > I'm not sure about this intuition, though I only have a counter intuition. > For the hosted scenario, a provider could simply set up an HTTPS endpoint for > their client domains, use SNI, and fetch SSL certs for the client as part of > a hosting package. For the self-hosted scenario, is it considerably harder? > I'm not sure, but given how easy it is to set up a personal HTTPS endpoint > with Let's Encrypt, I don't really see why. Am I far off base? While I see benefits to hosters, what I've seen from community projects like bettercrypto(.org) is there's a lot of misunderstanding on how to properly configure services, a lot of bad information sources around for sysadmins and barely any tooling to automate. Let's Encrypt now does automate on specific platforms and for specific daemons - we'll probably extend this to some degree for mail daemons in the future but there's also a lot of unwillingness among admins to use automation tools that require e.g. root. I feel that a lot of admins will reject going via HTTPS services just to serve mail in a secure fashion. I'm also not sure how willing software implementers will be to go this direction, but we'd better ask them. Thanks, Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
