[Top] [All Lists]

Re: [ietf-smtp] New proposal: SMTP Strict Transport Security

2016-03-21 12:40:54
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 "", 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; 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

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

Does that make sense?


On Mon, Mar 21, 2016 at 5:50 PM, David Schweikert 

Hi Mark,

On Mon, Mar 21, 2016 at 02:45:47 +0100, Mark Risher wrote:
The initial draft is at
draft-margolis-smtp-sts/ and we hope to discuss this at the Buenos Aires
meeting next month. While we have deployed a prototype/reference
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 and the way I
understand the current spec, is that the domain part must be ""
and can't be a subdomain, right? That might be a challenge...

What about possibly fetching the resource from an URL like ? That might make it easier to deploy,
because you don't need to deploy something completely unrelated on your

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.).


ietf-smtp mailing list