Subject: [Uta] Updated MTA-STS & TLSRPT

From: "Brotman, Alexander" <[email-masked]>
Date: Thu, 28 Sep 2017 20:42:15 +0000

Folks,

We've just uploaded new revisions for the drafts mentioned above.  Not a ton of changes, but wanted to share with the group.

MTA-STS: Added Policy Delegation and a few other clarifications

TLSRPT: Changed the domains associated with reporting, added examples for policy-strings, and added a MUST for not using l= for the DKIM signature

Please let us know if you have any comments or questions, and thank you for your time.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Sep 2017 17:02:05 -0400

> On Sep 28, 2017, at 4:42 PM, Brotman, Alexander <[email-masked]> wrote:
> 

I see that 302 HTTP redirects are still not supported, and that policy
delegation without SNI is via reverse proxying, rather than 302
redirects.  I may have missed the discussion that arrived at this
decision.  Is this the "rough consensus" view?

I would expected it to be easier to serve 302 redirects than deploy
a reverse proxy, but perhaps I am mistaken, and HTTPs servers come with
reverse-proxy support as a common built-in feature?

With reverse-proxying, would caching of the policy by the reverse proxy
be a reasonable strategy?  With the usual HTTP cache control headers
(rather than max_age) setting the duration?

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 29 Sep 2017 08:28:47 +0200

> decision.  Is this the "rough consensus" view?

May I suggest that if you would like to see redirects supported in
addition to instead of reverse proxy then provide text so we have
something concrete to discuss ?

> reverse-proxy support as a common built-in feature?

Speaking as an individual I'd say that modern general purpose webservers
do both equally well and just as easily. There may still be deployment
issues making one or the other preferable in any one situation though...

	Cheers Leif

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 29 Sep 2017 15:20:28 +0200

I actually wrote up a commit with 302 support: https://github.com/
mrisher/smtp-sts/commit/c41f24d8500f058073b5b78ac18e177f738146a5. However,
I didn't merge it in, since there was no clear consensus on the WG or among
the authors.

The argument *for* 302s is for added flexibility of hosting, of course,
especially on delegated policies. An example usage would be to allow people
like me, who have a personal domain with just an MX that points to Google,
to use a minimal HTTPS host (e.g. from their registrar) to point a 302 for
the policy host to Google's policy.

The argument *against* 302s is merely whether the extra complexity for MTA
implementors (to ensure proper validation of identities while traversing
redirects, as I wrote* in the commit linked below) is risky or can be
gotten wrong, or whether there are additional issues around difficulty
figuring out (e.g.) which certificate is not trusted by a sender if there
is some policy fetch failure.

I don't think redirects are either critical or fatal, so I would first and
foremost like to see the WG reach a consensus (quickly!) on whether to
support them or not.

 Leif, do you think it's reasonable to have a simple up-or-down vote on the
10 draft vs the additional text linked above, with a conclusion by (say)
end of next week?

Dan

* "Note that when following an HTTP 30x redirect, the aforementioned
certificate authentication MUST nonetheless be applied to the initial HTTPS
response that serves the 30x code; subsequent redirect URIs MUST also be
HTTPS with a server certificate that is trusted by the sending
MTA, non-expired, and valid for the host identity, though this identity may
differ from that the initial `mta-sts` host. (Thus, for example, `
https://mta-sts.user.com` may redirect requests to `
https://mta-sts.provider.com`, but the `provider.com` endpoint must also
be authenticated."

On Fri, Sep 29, 2017 at 8:28 AM, Leif Johansson <[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Leif Johansson <[email-masked]>
Date: Fri, 29 Sep 2017 17:00:22 +0200

>  Leif, do you think it's reasonable to have a simple up-or-down vote on
> the 10 draft vs the additional text linked above, with a conclusion by
> (say) end of next week?

Yeah I think folks who like the alternative text or some version of that
should speak up now so we can judge consensus on this issue.

By my reckoning this is the final post-WGLC issue and but for this we're
ready to push this to the IESG.

	Cheers Leif

---

From: James Cloos <[email-masked]>
Date: Fri, 29 Sep 2017 14:53:47 -0400

>>>>> "BA" == Brotman, Alexander <[email-masked]> writes:

BA> TLSRPT: Changed the domains associated with reporting, added
BA> examples for policy-strings, and added a MUST for not using l=
BA> for the DKIM signature

Looking at the diff, I noticed that the reference to RFC7159 (JSON) got
dropped.  Given that json is still in the draft, I can't tell whether
that was intentional.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6