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

From: Mark Risher <[email-masked]>
Date: Mon, 21 Mar 2016 02:45:47 +0100

[cross-posting from UTA mailing list as well)

Dear IETF-SMTP:
We have just submitted a proposal entitled SMTP Strict Transport Security,
which details a mechanism for protecting MTA-to-MTA email traffic against
TLS downgrade attacks and interception.

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.

Thank you for your consideration,

/m

---

From: David Schweikert <[email-masked]>
Date: Mon, 21 Mar 2016 17:50:13 +0100

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

---

From: David Schweikert <[email-masked]>
Date: Mon, 21 Mar 2016 18:13:40 +0100

Hi Daniel,

Thanks for your answers!

On Mon, Mar 21, 2016 at 18:03:27 +0100, Daniel Margolis wrote:
> 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. 

OK, nice.

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

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?

Cheers
David

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 21 Mar 2016 18:27:20 +0100

> Aren't you worried about the difficulty of updating the policy

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?

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 21 Mar 2016 18:03:27 +0100

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

---

From: David Schweikert <[email-masked]>
Date: Mon, 21 Mar 2016 21:12:12 +0100

Hi Daniel,

On Mon, Mar 21, 2016 at 18:27:20 +0100, Daniel Margolis wrote:
> 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).

> (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

---

From: Franck Martin <[email-masked]>
Date: Mon, 21 Mar 2016 17:12:30 -0500 (CDT)

----- Original Message -----
> From: "David Schweikert" <[email-masked]>
> To: "Daniel Margolis" <[email-masked]>
> Cc: "Wei Chuang" <[email-masked]>, "Mark Risher" <[email-masked]>, [email-masked]
> Sent: Monday, March 21, 2016 1:12:12 PM
> Subject: Re: [ietf-smtp] New proposal: SMTP Strict Transport Security
> 

> > new

may be a CNAME could do the same ?

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 22 Mar 2016 17:14:44 +0100

In the interests of unifying the threads, I'll drop this one and continue
on the main thread on the UTA mailing list. I think David's feedback is
obviated by Viktor's suggestion if we go that route, so it makes sense to
discuss the two together.

Sorry for the interruption.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 25 Mar 2016 15:54:31 -0700

Hello,
At 18:45 20-03-2016, Mark Risher wrote:
>We have just submitted a proposal entitled SMTP Strict Transport 
>Security, which details a mechanism for protecting MTA-to-MTA email 
>traffic against TLS downgrade attacks and interception.

There is an IPR disclosure at https://datatracker.ietf.org/ipr/2776/

Regards,
S. Moonesamy

---

From: Mark Risher <[email-masked]>
Date: Mon, 28 Mar 2016 08:08:21 -0700

Hi:
That disclosure was meant to remove any concern by making explicit that the
authors don't intend to restrict usage. Sorry if it accidentally had the
opposite effect.

/m

--
Mark E. Risher |  Group Product Manager |  [email-masked] |  650-253-3123

On Fri, Mar 25, 2016 at 3:54 PM, S Moonesamy <[email-masked]> wrote:

>> Security, which details a mechanism for protecting MTA-to-MTA email traffic
>> against TLS downgrade attacks and interception.
>>
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Mar 2016 09:45:48 -0700

Hi Mark,
At 08:08 28-03-2016, Mark Risher wrote:
>That disclosure was meant to remove any concern by making explicit 
>that the authors don't intend to restrict usage. Sorry if it 
>accidentally had the opposite effect.

It had the opposite effect; sorry about that.  I find the following 
easier: http://www.ietf.org/mail-archive/web/imapext/current/msg05778.html

Regards,
S. Moonesamy