Reporting: listing both DANE and MTA-STS policies

[aykevl]

Another nitpick here.
It is possible both DANE and MTA-STS are in use on a given domain, but the current reporting syntax does only allow exactly one policy, either MTA-STS or DANE.

MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow a "valid" or "report-only" MTA-STS validation to override a failing DANE validation.

  "policy": {
    "policy-type": policy-type,
    "policy-string": policy-string,
    "policy-domain": domain,
    "mx-host": mx-host-pattern
  },

(Offtopic: I'm assuming that a failing MTA-STS also must not override a working DANE implementation, although it isn't spelled out that way).

I have a few ideas for a different syntax, if needed.

Also, it isn't clear to me what a DANE policy string serialization should look like. Is it "_443._tcp.www.example.com. IN TLSA ( 0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 )" or only "0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971"? The second seems more obvious to me but the first is given in section 2.3 of RFC6698. An example might make it more clear. Serializing a JSON representation of a MTA-STS policy is a bit odd given that the current format is based on text (not JSON), but it could be helpful to diagnose syntax/parser problems.

[abrotman]

I'm not sure this needs to be represented this way anymore (serialized) given the STS policy is no longer JSON. As for me, I'd prefer the first example for TLSA as that includes the TLSA record being reported (for example, we have one for each data center, which may be useful information). Should we report the STS policy as a single-line string, with "!" separating the values (or any other format is fine with me)?

[danmarg]

(Offtopic: I'm assuming that a failing MTA-STS also must not override a working DANE implementation, although it isn't spelled out that way).

I would not assume so, or at least, would hesitate to specify as much. A sender who is compliant with STS and discovers a failing policy with mode=enforce should not deliver to that domain. That doesn't prevent a sender from implementing logic as to stop checking STS if a DANE TLSA record exists. But it's not something I would specify as required behavior, and is outside the scope of the spec. (It's a choice to not implement, not a part of the protocol, I think.)

Also, it isn't clear to me what a DANE policy string serialization should look like.

I'm with @abrotman on this. Let's add an example to be more clear.

Should we report the STS policy as a single-line string, with "!" separating the values
Why "!"? I would just do the literal string of the entire policy, as a JSON string. E.g.

"policy-string": "version: STSv1\nmode: report\npolicy_id: 12345\nmx: mail.example.com\nmax_age: 86400"

No?

[danmarg]

So the serialization issue was fixed, but the syntax still only allows specifying a single policy. Do we want to change this?