ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

2021-04-02 13:54:42
On Fri, Apr 02, 2021 at 07:00:05PM +0300, Kristijonas Lukas Bukauskas wrote:

{
  "organization-name": "Microsoft Corporation",
  "date-range": {
    "start-datetime": "2021-03-31T00:00:00Z",
    "end-datetime": "2021-03-31T23:59:59Z"
  },
  "contact-info": "tlsrpt-noreply(_at_)microsoft(_dot_)com",
  "report-id": "132617776923269755+n0.lt",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mx.n0.lt",
          "max_age: 84600"
        ],
        "policy-domain": "n0.lt"
      },
      "summary": {
        "total-successful-session-count": 0,
        "total-failure-session-count": 36
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "failed-session-count": 36
        }
      ]
    }
  ]
}


Is this a correct error to return, even if with CNAME/MX? (SANs are 
n0.lt and *.n0.lt in my cert.)

The error indicated is indeed misleading, since the problem appears
to rather be a mismatch between the CNAME-expanded MX hostname and
the "mx: " field of the MTA-STS policy.  The certificate matches
either name, so isn't plausibly the problem:

    mx.n0.lt. IN CNAME n0.lt.
    n0.lt. IN A 188.166.32.32

Mind you, I do think that the sender should (in due course) change their
MTA-STS implementation to process MX CNAMEs in a manner that does not
change the logical MX host that is compared against the STS policy.

Sure, given the RFC5321 language, and the relatively low impact, they
can choose to give the fix low priority, but inevitably this issue will
crop up from time to time, and it simpler to address it at some point
than to steadfastly point out that the receiving system is somewhat
outside the spec.

The reason to be lenient here, is that MTA-STS aside, RFC5321
notwithstanding, MTAs, including theirs, generally allow CNAMEs in the
MX record, and it is a nuisance if enabling MTA-STS, ... suddenly
breaks that, for non-obvious reasons.

However, as a receiving system, in the meantime, you can do yourself and
everyone else a favour by changing your DNS to avoid the CNAME.

Since you're also using DANE:

    n0.lt. IN MX 10 mx.n0.lt.
    mx.n0.lt. IN CNAME n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.mx.n0.lt. IN TLSA 3 1 1 
d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

that would be either:

    n0.lt. IN MX 10 mx.n0.lt.
    mx.n0.lt. IN A 188.166.32.32
    mx.n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.mx.n0.lt. IN TLSA 3 1 1 
d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

or alternatively:

    n0.lt. IN MX 10 n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.n0.lt. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.n0.lt. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.n0.lt. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.n0.lt. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.n0.lt. IN TLSA 3 1 1 
d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

You can use CNAMEs in TLSA RRs if you like:

    n0.lt. IN MX 10 n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.n0.lt. IN CNAME _25._dane.n0.lt.
    _25._dane.n0.lt. IN TLSA 2 1 1 
276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._dane.n0.lt. IN TLSA 2 1 1 
8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._dane.n0.lt. IN TLSA 2 1 1 
bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._dane.n0.lt. IN TLSA 2 1 1 
e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._dane.n0.lt. IN TLSA 3 1 1 
d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

-- 
    Viktor.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp