Re: [exim-dev] [Bug 2704] DANE client-side documentation iss…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Viktor Dukhovni
Datum:  
To: exim-dev
Betreff: Re: [exim-dev] [Bug 2704] DANE client-side documentation issues
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.