From haigui.chen@gmail.com Wed Feb 19 19:27:52 2020 Return-Path: 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 51CA1120099 for ; Wed, 19 Feb 2020 19:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TRNaA3cx85zT for ; Wed, 19 Feb 2020 19:27:51 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD94F12001B for ; Wed, 19 Feb 2020 19:27:50 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id r18so31959252edl.1 for ; Wed, 19 Feb 2020 19:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4LvEbkwNDgYHF3hksci6O6ZHH2jClS1TCtC1aLqBcM8=; b=pOIeeolegfMpAbplVKOMn67kb5WSGyEWsmF1xl/qIFm8h/NDFTqmG/MIE0C7IKLkqA o3WwmhMXemod+fk8+/5zpIoCPLp969x+YmEATnnOMVNUnzQL7awslZp6oGTWmxDMgp6K BKAM6QNDrY+GmxbrErPUnfbtbI+AzskVpMGoILz0mx69Cj+V+DG3vxZo+XzNiKvIqy8w eFePQLpM7EZotcxR1eDt7VmBCpCCpne/kdWLETQB6efI/prGDN5kUV+Dk9+a8gQ3QSQq nc4hHu0aFYBJO3/3A0bGN+ujVnq+kZuagey0aUz3VtMLndNm9U7zfw4K9BTxzNt73Gyq kq7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4LvEbkwNDgYHF3hksci6O6ZHH2jClS1TCtC1aLqBcM8=; b=O9Lol2/4C8TYFj2ZrTMpPB04PZst6EF8I+L8A2uvWuV0cSmGJ5SzAFx4iuybHjAi3o TWMwCu0vm2RFWyHxfuI2WYv31D2Cyft4hytbeJP1BdEOdgnp7k/e99bcujrD36ep244B RqArVPXGuCJmiWHShlFgwzDQydtZZAMMkQauF4F2LsdpS41qpwobK9LYgDgmFz2x2PWR /mhnSh6/1LCTgjeYj3euKXxPtTnFTk42cD9mH79Uo5zLIs40CXGou7Mfc7opgJ5NIngm NlVwtFl3FO2jJGZtJjG/az8ySV0R/ruzJJXwWJR8rBbj8zXnLjjUsiOHzTUbBUv4cGLk jAEg== X-Gm-Message-State: APjAAAVDOQ8hpRb245XTVPspVZrBl+b3gKNPnD4mu1fnN+tyAjrCtH3U mS/8n8hOpi+EKec4/iemyJrJluWS+bqCNZAXuHULQqsa X-Google-Smtp-Source: APXvYqwwXGAAzCrsrHbfere6jd5f5iyoCp+A7Gu+RS9zntBulXneZB35bJSEimaiucbFGjDINJDTLiCXxbN88ptclCU= X-Received: by 2002:aa7:da13:: with SMTP id r19mr26083052eds.188.1582169269074; Wed, 19 Feb 2020 19:27:49 -0800 (PST) MIME-Version: 1.0 From: Harvy Chen Date: Thu, 20 Feb 2020 11:27:38 +0800 Message-ID: To: dane@ietf.org Content-Type: multipart/alternative; boundary="000000000000420136059ef97d7d" Archived-At: X-Mailman-Approved-At: Thu, 20 Feb 2020 18:43:44 -0800 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 04:58:43 -0000 --000000000000420136059ef97d7d Content-Type: text/plain; charset="UTF-8" Hi All, Once studied the DANE RFCs, for the multiple tenant service providers, like this: Sender ----> Service -----> Rcpt. 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. Thanks, Haigui --000000000000420136059ef97d7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
=C2=A0 Once studied the DANE RFCs, for the mul= tiple tenant service providers, like this: Sender ----> Service ----->= ; Rcpt. How can it implement the DANE for inbound traffic? It requires the = customer's (rcpt) certificate, in TLS connection setup stage, we even d= on't know who is the rcpt, and cannot decide to use which certificate.<= /div>

Thanks,
Haigui

--000000000000420136059ef97d7d-- From nobody Thu Feb 20 19:21:30 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: dane@ietf.org Message-ID: <20200221032124.GZ49778@straasha.imrryr.org> Reply-To: dane@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From nobody Thu Feb 20 19:22:06 2020 Return-Path: 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 F11BE120814 for ; Thu, 20 Feb 2020 19:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 uEIx7Nt4lOhP for ; Thu, 20 Feb 2020 19:22:03 -0800 (PST) Received: from mail.webgo24-server5.de (mail.webgo24-server5.de [37.17.224.235]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FE6120233 for ; Thu, 20 Feb 2020 19:22:03 -0800 (PST) Received: from webgo24-server5.de (localhost [127.0.0.1]) by mail.webgo24-server5.de (Postfix) with SMTP id 4021193E1A7B for ; Fri, 21 Feb 2020 04:22:01 +0100 (CET) Received: (from peter@sylvester.computer) by webgo24-server5.de (mini_sendmail/1.3.6 20apr2017); Fri, 21 Feb 2020 04:22:01 CET (sender root@webgo24-server5.de) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit To: dane@ietf.org From: =?ISO-8859-1?B?V2VibWFzdGVy?= Message-Id: <20200221032201.4021193E1A7B@mail.webgo24-server5.de> Date: Fri, 21 Feb 2020 04:22:01 +0100 (CET) Archived-At: Subject: [dane] =?iso-8859-1?q?This_email_address_is_no_longer_available?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 03:22:05 -0000 This email address is no longer available