Subject: [Uta] Updated MTA-STS & TLSRPT Drafts

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 21 May 2018 20:41:54 +0000

Hello,

We have just uploaded a new revision for each of the above drafts.  We believe we've incorporated all of the most recent feedback from reviewers.  The largest change for MTA-STS was relating to the MX/SAN matching.  For TLSRPT, we added a field for the DKIM record, removed mention of the compression for HTTP submissions, and there were several cleanup items.

Please take a look and get back to us with any comments.  Thank you for your time and effort.

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

---

From: James Cloos <[email-masked]>
Date: Mon, 21 May 2018 19:38:17 -0400

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

BA> We have just uploaded a new revision for each of the above drafts.

You added this text;

id> Note that in all such cases, the policy endpoint ("https://mta-
id> sts.user.example/.well-known/mta-sts.txt" in this example) must still
id> present a certificate valid for the Policy Domain ("user.example"),
id> and not for that of the provider ("provider.example").

Should that be "mta-sts.user.example" vs "mta-sts.provider.example"?

As is, it gives the impression that the policy host ought to provide a
cert for the policy domain rather than for itself.

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

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 23 May 2018 10:12:21 -0400

That's right. Good catch. Per the rules of cert validation (from rfc6125),
user.example would also be valid, but the example is misleading. I'll cut a
new draft really quickly with this change. :)

On Mon, May 21, 2018 at 7:38 PM James Cloos <[email-masked]> wrote:

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 23 May 2018 10:14:54 -0400

[ Accidentally sent to just uta-chairs the other day, fixed, sorry ]

> On May 21, 2018, at 7:38 PM, James Cloos <[email-masked]> wrote:
> 

Agreed.   A fix might be: s/Policy Domain/Policy Host/

I should have noticed a few other editorial issues earlier:

1. OLD:

                       If the number of resulting records is not
  one, senders MUST assume the recipient domain does not have an
  available MTA-STS policy and skip the remaining steps of policy
  discovery.  (Note that lack of an available policy does not signal
  opting out of MTA-STS altogether if the sender has a previously
  cached policy for the recipient domain, as discussed in Section 5.1,
  "Policy Application Control Flow".) 

  NEW:

                       If the number of resulting records is not
  one, senders MUST assume the recipient domain does not have an
  available MTA-STS policy and skip the remaining steps of policy
  discovery.  (Note that absence of a usable TXT record is not
  by itself sufficient to remove the sender's previously
  cached policy for the recipient domain, as discussed in Section 5.1,
  "Policy Application Control Flow".) 

2. OLD:

   Thus for a Policy Domain of "example.com" the path is
   "https://mta-sts.example.com/.well-known/mta-sts.txt".

  NEW: s/path/full URL/

3. OLD (possible confusion as to which should not be expired):

  The certificate presented by the receiving MTA MUST chain to a root
  CA that is trusted by the sending MTA and be non-expired.  

  NEW:

  The certificate presented by the receiving MTA MUST not be expired,
  and must chain to a root CA that is trusted by the sending MTA.  

-- 
	Viktor.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 23 May 2018 10:22:29 -0400

Thanks. Easy fixes. Done in -19:
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/.