Re: [Uta] New proposal: SMTP Strict Transport Security

[Viktor Dukhovni <[e-mail]>]

On Tue, Mar 22, 2016 at 11:10:57AM +0100, Daniel Margolis wrote:

> Thanks for the feedback to both of you. I don't disagree; I think Viktor
> makes a very solid point in favor of simplicity. In addition, a report-only
> protocol could be extended to support arbitrary error reporting; an
> out-of-band (e.g. HTTP) channel to share delivery failures between domains
> strikes me as useful in the general case.
> 
> Separately, because we're already assuming providers (both sending and
> receiving) make a choice on implementing DANE and/or webPKI, I don't think
> actually splitting the two makes it any more or less complex to implement,
> or should discourage adoption of one or the other mechanism.
> 
> So I would say I'm feeling a bit in favor of Viktor's suggestion, but I'd
> like to chat a bit more with my co-authors and think about it first. ;)

Great.  One more question.  I see that there are parallel
non-overlapping threads on this proposal on tha UTA and IETF-SMTP
lists.  Is either the "primary" forum for discussing this proposal?
Should people be encouraged to cross-post?  Should the IETF-SMTP
users who want to discuss it be encouraged to shift the discussion
here?

> Viktor, as an aside regarding the hosted mail scenario, we already had the
> suggestion to move the HTTPS endpoint to something like "_
> smtp_sts.example.com/current". If we do that, the customer (example.com)
> can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI to
> serve the policy with the customer's cert (assuming the customer trusts the
> hosting provider with this; for domains that don't operate their own HTTPS
> endpoint this seems to me to be likely). For the more complex case, the
> cron setup you describe doesn't seem too onerous, I agree.

Prepending a fixed sub-domain label is fine as an extra bit of rope
to support various forms of indirection.

-- 
	Viktor.