On Mon, Mar 21, 2016 at 6:13 PM, David Schweikert
<david(_at_)schweikert(_dot_)ch>
wrote:
But isn't that a problem? It means that you are going to have many
copies of the same policy, as it was when the customers copied it.
Aren't you worried about the difficulty of updating the policy
everywhere?
Yes, a little. I think how concerning this is depends (as you implied) on
how specific (or prone to staleness) the policy is. A statement like "I
will always have a CA-signed cert and an MX matching this pattern" is
scarcely any more prone to staleness than the provider's MX records, which
users already copy into their zone. A statement like, "My certificate
fingerprint is X" is, as you implied, probably more prone to staleness.
I think there are a couple of options for addressing this that involve some
mechanism of policy "pointers". For example, you could instead say that the
policy RR (_smtp_sts.example.com) is merely a pointer to either a HTTPS URI
(which contains the policy potentially served via an SNI-aware server) or a
new DNSSEC-served record (depending on your preferred authentication
mechanism). By this approach the perishable bits of a policy can be hosted
by the MX provider and the *existence* of a policy still indicated by the
policy domain owner.
This is something we haven't addressed in the current draft in part
because, I think, the current policies are mostly non-perishable, but I
think such a mechanism may make sense (either now or as a feature of an
expanded mechanism that includes certificate pinning or similar, more
brittle specifications). What do you think?
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp