ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Email explained from first principles

2021-05-17 16:24:07
On Fri, May 14, 2021 at 03:27:07PM +0200, Kaspar Etter wrote:

8. It's rather complicated in which cases DANE applies to ESMTP. I
hope I got all the cases right:
https://explained-from-first-principles.com/email/#name-matching

I guess this one falls on me.

  If a certificate usage other than DANE-EE is being used, DANE clients
  have to verify that the validated certificate matches the server’s
  identity. In order to do so, they carry out the following, rather
  complicated and boring procedure:

This can be made more intuitive (if not necessarily simpler).

      Determine the TLSA domain: The TLSA lookup is usually performed
      on the server’s domain after resolving any CNAME, MX, and SRV
      records. RFC 7672, however, makes things a bit more complicated
      for ESMTP.

One simplifying observation is that the "TLSA base domain" (what you've
shortened to the TLSA domain) is wherever the TLSA records were found!

A. If TLSA records were found via a query for "_25._tcp." prepended
   to some "base domain", then the TLSA base domain is THAT domain.
   [ This is the name used to make the query, not any CNAME expansion
     that may happen as part of resolving that name to a an actual TLSA
     RRset. ]

B. In addition, the TLSA base domain is always associated with the
   logical nexthop server to which the mail will be relayed, i.e. the
   "MX host".  Which may be implicitly equal to the recipient domain if
   that domain has no MX records (per RFC5321, 2821 and 821).

   In a DANE-enabled SMTP client the MX lookup is performed via a
   security-aware or validating stub resolver, that can determine
   whether the MX records (or their denial of existence) were signed.

   If the MX lookup leads to an insecure answer, DANE does not apply.
   [ See "H." below for a note on DNS error semantics. ]

C. Regardless of whether that logical nexthop domain is explicit or
   implicit, since a connection is going to be made to it, one needs
   to obtain its address records (some combination of A/AAAA).

D. Resolving that logical name to an address RRset (or two) via
   a validating resolver will also reveal whether those addresses
   lie in a signed zone.

E. If one or more of the address RRSets (IPv4 "A" and/or IPv6 "AAAA") is
   signed (it is possible, e.g. for the IPv4 address RRSet to come
   secure, while denial of existence of IPv6 addresses to come back
   insecure, or vice versa), then check for TLSA records at the fully
   nexthop server domain (see "H." below).

   * If found (see "A." above), that's the TLSA base domain.
   * If none found (NODATA or NXDOMAIN), continue with "F." or "G."
     as appropriate.

F. If no address RRSet zone is signed, and there is no CNAME expansion
   involved in getting from the logical name to the addresses, DANE is
   not possible, proceed without DANE.

G. When either:

   i.  "E." above yields no TLSA records, or

   ii. In "F." above, CNAMEs lead to all addresses being insecure, it is
       possible that the origin zone is signed, and it is only the
       target zone with the addresses (or some CNAME in a multi-step
       CNAME chain) that is insecure.

       To determine whether that's the case, a security-aware stub
       resolver needs to issue an explict "CNAME" query for the
       unexpanded name, and determine its security status.  A validating
       stub resolver (not widely used) may already know this as part of
       validating the query response.

       If the original unexpanded name is also unsigned, DANE is not
       possible, proceed without DANE. Otherwise,

    Look for TLSA records of the original unexpanded server name
    (prepending _25._tcp. ...).

H.  TLSA record lookup failures are security sensitive.  Acceptable
    outcomes are:

    i. Success, signed validated TLSA records.  DANE MUST be used.
    ii. Unsigned TLSA records.  DANE does not apply.
    iii. Signed or unsigned denial of existence (NODATA or
         NXDOMAIN).  DANE does not apply.

    All other outcomes (SERVFAIL, REFUSED< BOGUS, timeout, ...)
    are potential downgrade attacks, and the MX host in question
    is skipped, possibly leading to the message being deferred if
    no other candidate MX hosts remain.

I.  By this point we have one of:

    - TLSA records and an associated "TLSA base domain"
    - Proof that the records don't exist, or that all zones in
      which we might have tried to look are unsigned.
    - A lookup failure, which means we skip the MX host.

    In either of the latter cases no DANE.

J.  The TLSA base domain is therefore either:

    i. A CNAME expanded nexthop server
    ii. The original nexthop server.

    Either could be the same as the recipient domain, or its CNAME
    expansion.  Note that the TLSA RRset itself may involve CNAME
    expansion, this is normal, and DOES NOT affect the TLSA base
    domain which is always the query name, not the domain

    Wherever the TLSA base domain came from, the SMTP client uses this
    TLSA base domain as the SNI value for the TLS handshake with the
    target SMTP server.

K.  For purposes of certificate verification the client builds a list
    "reference identifiers" that will compared against the names found
    in the peer certificate (the "presented identifiers").

    The list of "reference identifiers":

        - Always includes the TLSA base domain

        - Will also include the unexpanded name of the MX host, if
          different from the TLSA base domain.

        - Will also include the unexpanded recipient domain if different
          from those above.

L.   The presented identifiers are compared against the reference
     identifiers until one pair matches, per RFC6125, wildcards in
     presented identifiers, ...

Twelve steps should about (re)cover it.

    First of all, the domain found after the @ symbol in the email
    address is CNAME-expanded. If the whole expansion was secure, you
    look up its MX records.

Well, you look up MX records either way, it is just that if they or
their absence is insecure, DANE is off the table.

    Any domain name listed in an MX record has to resolve directly to
    A/AAAA records according to RFC 2181 and RFC 5321.

True, but most MTAs are more liberal, and support CNAME expansion of
also the MX hosts (though a my survey shows only ~1% of DANE MX hosts to
be CNAME-valued).

    If the expanded @ domain has no MX records, you fall back to its
    A/AAAA records.  The TLSA domain is determined as follows:

See above for the the full procedure.

      
------------------------------------------------------------------------------------
      Non-expanded @ domain | Expanded @ domain | MX domain        | TLSA 
domain
      
====================================================================================
   1. Secure CNAME record   | Secure MX records | Secure A/AAAA    |
                            |                   | and TLSA records | MX domain
      
------------------------------------------------------------------------------------
   2. Secure CNAME record   | Secure A/AAAA     | -                | Expanded 
@ domain
                            | and TLSA records  |                  |
      
------------------------------------------------------------------------------------
   3. Secure CNAME record,  |                   | -                | 
Non-expanded @ domain
      secure TLSA records   | Insecure A/AAAA   |                  |
      records               |                   |                  | [some 
glyph]
      
------------------------------------------------------------------------------------
   4. Secure MX records     | -                 | Secure A/AAAA    | MX domain
                            |                   | and TLSA records |
      
------------------------------------------------------------------------------------
   5. Insecure MX records   | -                 | Secure A/AAAA    | MX domain
                            |                   | and TLSA records | [some 
glyph]
      
------------------------------------------------------------------------------------
   6. Secure A/AAAA         | -                 | -                | 
Non-expanded @ domain
      and TLSA records      |                   |                  |
      
====================================================================================

The above does not cover short-circuiting TLSA lookup when both the A
and AAAA RRsets come back insecure.

It also assumes that the MX host is NOT CNAME expanded (per 5321), in
practice many MTAs (e.g. at least Postfix and Exim) allow this.

Case "5" is not possible, the MX records and A/AAAA records are obtained
from the same zone, and so the security status should be the same, also
insecure TLSA records are not used.


      In all other cases, DANE does not apply. I’ve marked the
      unexpected cases with [some glyph] 

It is not clear what's "unexpected" about them.

      RFC 7672 allows ESMTP clients to use DANE even if the MX records
      were in a zone whose records aren’t authenticated with DNSSEC.

True, provided that the MX host (different from the recipient domain
or its CNAME expansion) is in a signed zone.  But this is optional,
and the MTAs logs must not claim secure delivery in this case.  DANE
protects the transport to a possibly forged MX host in this case.

  If you implement an ESMTP client, you can avoid all of this
  complexity by supporting only the certificate usage DANE-EE.

Actually, you don't avoid most of the work, because the only thing that
changes is construction of the reference identifier list.  One must
still locate the TLSA records correctly, construct the correct SNI name,
otherwise you may get the wrong certificate and fail to match even a
DANE-EE RRset.

So the above is bad advice.  Many domains are using DANE-TA(2), which
SHOULD be supported.

-- 
        Viktor.

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