Hey, David,
Thanks for the kind words. You're spot on about the URI paths, and this is
in fact a point of ongoing discussion. I'm currently going over a
suggestion to change this to "policy._smtp_sts.example.com/current", which
I think has basically the property you describe. (There's some nuance here
about whether we should be worried about zones with untrusted subdomains,
as in dyndns.org; if you can serve a bad policy for a domain you can DoS
them, but you can do that anyway with poisoned MX records, so it's not
clear to me we really need to worry here or not. A doubly-nested subdomain
was I think in part proposed to mitigate such a risk.)
An alternative would be to embed the URI of the policy directly in the
spec. But I don't think the difference here is critical, since in either
case you are using some DNS lookup to determine where to get the
policy--either a TXT record that has a URI in it or an A record (or
whatever) directly.
So, tl;dr: yes, we will probably do exactly what you said and use a
subdomain.
Regarding the hosted provider case, I think you're exactly right. In the
near-term, if you were fairly sure your provider would always have a
CA-signed cert or a TLSA record for their MXs, you could just on your own
initiative serve a policy for your domain that says so. But the safer way
to deploy this is probably more a model like how our hosted users deploy
DKIM: we generate a policy for them and say, "Paste this in your zone
file."
Does that make sense?
Dan
On Mon, Mar 21, 2016 at 5:50 PM, David Schweikert
<david(_at_)schweikert(_dot_)ch>
wrote:
Hi Mark,
On Mon, Mar 21, 2016 at 02:45:47 +0100, Mark Risher wrote:
The initial draft is at https://datatracker.ietf.org/doc/
draft-margolis-smtp-sts/ and we hope to discuss this at the Buenos Aires
meeting next month. While we have deployed a prototype/reference
implementation
among the authors, we are very open to feedback and suggestions from the
broader group and look forward to your input.
I find this really interesting, thanks for it! I especially like also
the DMARC-style reporting, which really should help administrators in
deploying this. When the day comes that DANE is well-established, it
could be that the reporting functionality is what really remains as
useful in SMTP STS.
Something that I wondered, is how easy it is for people to deploy a HTTPS
resource using the mail-domain as domain. You mentioned as an example
https://example.com/.well-known/smtp-sts/current and the way I
understand the current spec, is that the domain part must be "example.com"
and can't be a subdomain, right? That might be a challenge...
What about possibly fetching the resource from an URL like
https://_smtp_sts.example.com/... ? That might make it easier to deploy,
because you don't need to deploy something completely unrelated on your
homepage.
Also, I wonder how this is supposed to work for big hosters (like Google
:)): are customers going to copy-paste the Google policy for their
Google-hosted domains? This might get more and more problematic if more
features are added to the spec (like CA-pinning, etc.).
Cheers
David
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp