Hi Daniel,
On Mon, Mar 21, 2016 at 18:27:20 +0100, Daniel Margolis 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.
Yes, I agree that it depends on how often you need to update the policy
(and how important that change is).
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.
Yes. I was also thinking that having one level of indirection might
better fit the SMTP model of mail domain and mail hosts. Let me make
an example to see if I understand you right:
The _smtp_sts.example.com RR could contain the policy like
"redirect:gmail.com" and also publish that same information under
https://policy._smtp_sts.example.com. Then, any client would need to
access and authenticate two HTTPS resources:
- https://policy._smtp_sts.example.com -> redirect:gmail.com
- https://policy._smtp_sts.gmail.com -> mx:... a:...
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?
Yes, I agree. This might be a bit overkill at this moment. Still, it
might be useful to design it like that from the start.
Cheers
David
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp