Subject: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)

From: [email-masked]
Date: Wed, 26 Sep 2018 09:52:30 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 8461

        Title:      SMTP MTA Strict Transport Security 
                    (MTA-STS) 
        Author:     D. Margolis, 
                    M. Risher,
                    B. Ramakrishnan,
                    A. Brotman,
                    J. Jones
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2018
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      29
        Characters: 59461
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-uta-mta-sts-21.txt

        URL:        https://www.rfc-editor.org/info/rfc8461

        DOI:        10.17487/RFC8461

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
mail service providers (SPs) to declare their ability to receive
Transport Layer Security (TLS) secure SMTP connections and to specify
whether sending SMTP servers should refuse to deliver to MX hosts
that do not offer TLS with a trusted server certificate.

This document is a product of the Using TLS in Applications Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: "A. Schulze" <[email-masked]>
Date: Sat, 29 Sep 2018 20:13:20 +0200

> that do not offer TLS with a trusted server certificate.

Hello WG,

I consider implementing MTA-STS on our platform hosting thousand+ Domains.
Now I just found the following text:

   Note that in all such cases, the policy endpoint
   ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
   example) must still present a certificate valid for the Policy Host
   ("mta-sts.user.example"), and not for that host at the provider's
   domain ("mta-sts.provider.example").

Does that really mean I have to setup thousand+ virtual hosts https://mta-sts.domain1...1000.example?
Or are there other strategies for hosting provider?

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 29 Sep 2018 14:36:04 -0400

> On Sep 29, 2018, at 2:13 PM, A. Schulze <[email-masked]> wrote:
> 

Yes.

> Or are there other strategies for hosting provider?

None that I know of.

-- 
	Viktor.

---

From: Hanno Böck <[email-masked]>
Date: Sun, 30 Sep 2018 08:56:32 +0200

On Sat, 29 Sep 2018 20:13:20 +0200
"A. Schulze" <[email-masked]> wrote:

> I consider implementing MTA-STS on our platform hosting thousand+
> Domains. Now I just found the following text:
> 
> Does that really mean I have to setup thousand+ virtual hosts
> https://mta-sts.domain1...1000.example? Or are there other strategies
> for hosting provider?

This seems to be the one thing that is confusing a lot of people about
MTA-STS. The answer is yes you have to, no, there are no other
strategies.

The policy host is the thing that ties your domain name's identity to
your policy. This makes sure you can only serve a policy for
user.example if you control and have a certificate for user.example.
If you could serve a policy for user.example on provider.example you'd
not have that connection.

There is of course a good solution for this: Automate your virtual host
and certificate creation.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 30 Sep 2018 03:15:02 -0400

> On Sep 30, 2018, at 2:56 AM, Hanno Böck <[email-masked]> wrote:
> 
> your policy. 

This is one way in which DANE is less onerous.  For a domain with
signed MX records, the TLSA records are in the provider's zone
at _25._tcp.the.mxhost.example.  Allowing just one TLSA RRset
managed by the provider to take care of all the (signed) hosted
domains.  This works even when the MX hosting provider does not
control the customer's domain, and is not in a position to
obtain the requisite certificates.  In that case setting up the
MTA-STS policy is up to the customer.

-- 
	Viktor.

---

From: "A. Schulze" <[email-masked]>
Date: Sun, 30 Sep 2018 11:33:26 +0200

> MTA-STS policy is up to the customer.

Hello,

thanks for clarification.

As a side effect one could enumerate domains supporting MTA-STS just by watching the CT logs.

Andreas