Subject: [Uta] MTA-STS: A Key-Value Alternative

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 17 Jul 2017 19:17:08 +0000

Hello,

The authors of the MTA-STS draft and the UTA group have been attempting to reach a consensus on the issue of JSON versus KV for the policy file that is served via HTTPS.   In order to attempt to get over that issue, we've made a rough draft[1] that now uses key-value pairs instead of JSON.  Overall, our preference would be to stay with JSON as the alteration will break existing and in-progress implementations, but we'd really like to move forward.  We'd like to work toward a conclusion and welcome comments from the group.

[1] https://raw.githubusercontent.com/mrisher/smtp-sts/KV_Version/mta-sts.txt

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

---

From: David Illsley <[email-masked]>
Date: Mon, 17 Jul 2017 20:36:49 +0100

Is there a proposed Media Type/Content Type header value for this (can't
see one in the diff)? One of the nice things about JSON is that web servers
are likely to serve .json files as something appropriate out of the box.

On Mon, Jul 17, 2017 at 8:17 PM, Brotman, Alexander <
[email-masked]> wrote:

> Hello,
>
> The authors of the MTA-STS draft and the UTA group have been attempting to
> reach a consensus on the issue of JSON versus KV for the policy file that
> is served via HTTPS.   In order to attempt to get over that issue, we've
> made a rough draft[1] that now uses key-value pairs instead of JSON.
> Overall, our preference would be to stay with JSON as the alteration will
> break existing and in-progress implementations, but we'd really like to
> move forward.  We'd like to work toward a conclusion and welcome comments
> from the group.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 17 Jul 2017 20:09:03 +0000

I created this as a “.policy”, but unfortunately left out the new Content-Type that would need to be declared.  The idea of the rough draft was really to give folks an idea of what it would like, and stir the discussion.  We could obviously change this to something that is more well-known (txt or similar) so that we don’t need to do this.

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

From: David Illsley [mailto:[email-masked]]
Sent: Monday, July 17, 2017 3:37 PM
To: Brotman, Alexander <[email-masked]>
Cc: [email-masked]
Subject: Re: [Uta] MTA-STS: A Key-Value Alternative

Is there a proposed Media Type/Content Type header value for this (can't see one in the diff)? One of the nice things about JSON is that web servers are likely to serve .json files as something appropriate out of the box.

On Mon, Jul 17, 2017 at 8:17 PM, Brotman, Alexander <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

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

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

---

From: James Cloos <[email-masked]>
Date: Mon, 17 Jul 2017 17:33:55 -0400

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

> [1] https://raw.githubusercontent.com/mrisher/smtp-sts/KV_Version/mta-sts.txt

First, the KV style will work better than json.  +1

The rfc should specify what an sts client do with a mode:report when
there is no _smtp-tlsrpt RR?

I presume it should just skip reporting, but it should be specified.

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

---

From: James Cloos <[email-masked]>
Date: Mon, 17 Jul 2017 17:40:32 -0400

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

AB> We could obviously change this to something that is
AB> more well-known (txt or similar) so that we don’t need to do this.

text/plain works.  It could be something like text/kv or text/key-value,
but the doc should say that all clients MUST accept text/plain.

-JimC

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 18 Jul 2017 15:26:50 +0200

What to do without any TLSRPT support is sort of implied:

   1.  "report": In this mode, sending MTAs merely send a report (as
       described in the TLSRPT specification (TODO: add ref)) indicating
       policy application failures.

Of course, per the TLSRPT specification, if there's no TLSRPT RR, there's
no reporting. ;)

Granted, it may be isn't quite as explicit as it should be. Do you think we
need to call that out (i.e. "if senders and recipients both implement
TLSRPT")?

---

From: James Cloos <[email-masked]>
Date: Tue, 18 Jul 2017 11:12:30 -0400

>>>>> "DM" == Daniel Margolis <[email-masked]> writes:

DM> Of course, per the TLSRPT specification, if there's no TLSRPT RR, there's
DM> no reporting. ;)

DM> Granted, it may be isn't quite as explicit as it should be. Do you think we
DM> need to call that out (i.e. "if senders and recipients both implement
DM> TLSRPT")?

Yes, that was my point.  This doc should be explicit in that case.

There a lots of ways to word it, your quote above works.

-JimC