On Sun, Feb 28, 2021 at 07:04:58AM +0000, admin--- via Exim-dev wrote:
> This quoting was too selective. - Could you please post a corrected
> clomplete pseudocode? I cannot specify exactly what is wrong/unclear
> with the documentation (and come up with a patch) unless I have an
> understanding of what exim actually does.
Regardless of what it does, in order to be a correct implementation
of DANE it SHOULD:
- When DANE is opportunistic (not apriori mandated by local
policy for some set of destinations that MUST have DANE
TLSA records):
- Check that the destination domain has DNSSEC-signed MX
records. If not, continue with normal opportunstic TLS.
- Check that the current MX host is in a DNSSEC-signed zone.
(Its A/AAAA records are signed or result from a CNAME
chain whose first "link" is DNSSEC signed).
If not, continue with normal opportunstic TLS.
- If the MX A/AAAA records are an end-to-end signed CNAME
chain (all links signed), then look for TLSA RRs first
at the end of the chain. If no TLSA records found there,
or if not a chain or chain not signed end-to-end, look
for TLSA RRs at the original MX name.
When looking for TLSA RRs, prepend _<port>._tcp to the
candidate "TLSA base domain", and check the status of
the answer:
* If signed TLSA RRs found (AD=1), bingo, use these.
* If NODATA or NXDOMAIN (secure or insecure), fine,
no TLSA records for this candidate base domain.
* If insecure answer, likewise.
* Any query status other than answers, NODATA, or
NXDOMAIN is a hard error for the MX host in question.
Continuing to use the MX host would open up downgrade
attacks.
- If no signed TLSA RRs found, continue with normal
opportunistic TLS.
- Otherwise, use the obtained TLSA records to require that
the MX host provides STARTTLS and refuse to downgrade to
cleartext.
- If any of the TLSA records are "usable", require that the
presented certificate chain validates against these TLSA
records. Most sensible server operators avoid all TLSA
usages other than "3 1 1" and "2 1 1", but the client
should be willing to validate any "2 [01] [012]" or
"3 [01] [012]" record. On authentication failure, terminate
the connection without delivering mail.
With "2 X [12]" records, the issuing CA certificate MUST be
included in the server's certificate chain message.
- If none of the TLSA records are usable, just enforce STARTTLS,
without authentication.
- When DANE is mandated by local policy, do all the above, but
never fallback to cleartext or unauthenticated TLS. Instead
just skip the MX host if signed TLSA records that authenticate
the remote chain are not available.
> | A TLSA lookup will be done if either of the above options match and the
> | host-lookup succeeded using DNSSEC. If a TLSA lookup is done and
> | succeeds, a DANE-verified TLS connection will be required for the host.
> | If it does not, the host will not be used; there is no fallback to
> | non-DANE or non-TLS.
>
> Which translates to
> if ( (hosts_require_dane OR hosts_try_dane)
> AND successful DNSSEC host-lookup) {
> check for TLSA record
> if there is a TLSA record
> require DANE-verified TLS connection
> else /* reading "If it does not" as "no TLSA found" */
> skip host
There is in the text you quote a failure to distinguish between two
types of "success":
A. The query did not fail, returning an answer, NODATA, or
NXDOMAIN.
B. The query returned a DNSSEC-validated non-empty answer.
If "A" fails, the host MUST be skipped, no fallback, ... If only "B"
fails, then unless DANE is *required*, the MX host should be used
with normal opportunstic TLS.
--
Viktor.
