Re: [dane] How a multiple tenant SMTP service provider implement the DANE

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 21 February 2020 03:21 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE6E120814 for <dane@ietfa.amsl.com>; Thu, 20 Feb 2020 19:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt3eCMjsUq7a for <dane@ietfa.amsl.com>; Thu, 20 Feb 2020 19:21:25 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1523D120233 for <dane@ietf.org>; Thu, 20 Feb 2020 19:21:25 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3437C198C7B; Thu, 20 Feb 2020 22:21:24 -0500 (EST)
Date: Thu, 20 Feb 2020 22:21:24 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20200221032124.GZ49778@straasha.imrryr.org>
Reply-To: dane@ietf.org
References: <CAMawrWfNG9C7BB6b+7jD__DAZ=CuDMFjfdRTFua3bXatBeDtWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMawrWfNG9C7BB6b+7jD__DAZ=CuDMFjfdRTFua3bXatBeDtWw@mail.gmail.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/I7JgYsSg_6sIrD_izPF97gQ5iMg>
Subject: Re: [dane] How a multiple tenant SMTP service provider implement the DANE
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 03:21:28 -0000

On Thu, Feb 20, 2020 at 11:27:38AM +0800, Harvy Chen wrote:

> Once studied the DANE RFCs, for the multiple tenant service providers,
> like this: Sender ----> Service -----> Rcpt.

With DANE for SMTP the client authenticates the MX host, not the
recipient domain.  All the recipient domain has to do is have
DNSSEC-signed MX records.

As the provider your first responsibility to *monitor* your service
that you are promptly notified and take action to remediate any
situation in which your TLSA records for some reason stop matching
your certificate chain (e.g. poorly-executed certificate rollover).

Your next responsibility is to have a robust certificate rollover
process that avoids the potential outages that the monitoring
would detect.

    https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
    https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
    https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
    https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

> How can it implement the DANE for inbound traffic? It requires the
> customer's (rcpt) certificate, in TLS connection setup stage, we even
> don't know who is the rcpt, and cannot decide to use which
> certificate.

You DO NOT need certificates for the recipient domain, you just need
certificates for the supported name(s) under which your MX hosts are
known.

Example:

    ; Some domains with DNSSEC-signed MX records that are MX-hosted
    ; by sitnet.dk (there are many more):
    ;
    hirschsprung.dk. IN MX 10 mx5.sitnet.dk.
    hirschsprung.dk. IN MX 10 mx6.sitnet.dk.
    udbudsraadet.dk. IN MX 10 mx5.sitnet.dk.
    udbudsraadet.dk. IN MX 10 mx6.sitnet.dk.
    kunststyrelsen.dk. IN MX 10 mx5.sitnet.dk.
    kunststyrelsen.dk. IN MX 10 mx6.sitnet.dk.
    ...

    ; The A records of sitnet.dk are also DNSSEC-signed
    ;
    mx5.sitnet.dk. IN A 188.64.157.5
    mx5.sitnet.dk. IN AAAA ? NODATA AD=1

    ; Both MX hosts also have DNSSEC-signed TLSA records.
    ;
    _25._tcp.mx5.sitnet.dk. IN TLSA 3 1 1 d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7
    _25._tcp.mx6.sitnet.dk. IN TLSA 3 1 1 d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7

    ; Their certificates matches these TLSA records. With RFC7672
    ; DANE SMTP, when using DANE-EE(3) (certificate usage 3) TLSA
    ; records, the names in the certificate are irrelevant.  They
    ; are implicit in the TLSA RR owner name (_25._tcp + "TLSA base
    ; domain").
    ;

    mx5.sitnet.dk[188.64.157.5]: pass: TLSA match: depth = 0, name = *.sitnet.dk
    mx6.sitnet.dk[188.64.157.6]: pass: TLSA match: depth = 0, name = *.sitnet.dk
      TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384,P256
      name = sitnet.dk
      name = *.sitnet.dk
      depth = 0
        Issuer CommonName = Sectigo RSA Domain Validation Secure Server CA
        Issuer Organization = Sectigo Limited
        notBefore = 2019-03-04T00:00:00Z
        notAfter = 2021-03-03T23:59:59Z
        Subject CommonName = sitnet.dk
        pkey sha256 [matched] <- 3 1 1 d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7
      ...

If your MX hosts support SNI, you can if desired have separate
certificates for a few different names of each MX host.  If
your MX support both RSA and ECDSA (configured with separate
certificates for each algorithm), then you need multiple TLSA
records to match these:

    https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html

-- 
    Viktor.