From ietf-dane at dukhovni.org Thu Dec 29 06:09:26 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Dec 2016 05:09:26 +0000 Subject: Update on stats (no major changes) Message-ID: <20161229050926.GB27197@mournblade.imrryr.org> As of today I count 105264 domains with correct DANE TLSA records for SMTP. As expected the bulk of the DANE domains are hosted the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 42300 domeneshop.no 33519 transip.nl 15205 udmedia.de 1748 bhosted.nl 1292 nederhost.net 897 ec-elements.com 387 core-networks.de 300 uvt.nl 266 bit.nl 227 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for any ccTLDs, and in particular .de and .nl. There are 2269 unique zones in which the underlying MX hosts are found, this counts each of the above registrars as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. Alternatively, a similar number is seen in the count (2349) of distinct MX host server certificates that support the same ~105000 domains. Of the ~105000 domains, 825 have "partial" TLSA records, that cover only a subset of the MX hosts. While this protects traffic to some of the MX hosts, such domains are still vulnerable to the usual active attacks via the remaining MX hosts. The number of domains with incorrect TLSA records or failure to advertise STARTTLS (even though TLSA records are published) stands today at 75 (~25 are recent additions that will likely be resolved soon, the remaining ~50 are the long-term stable population of broken domains). The number of domains with bad DNSSEC support is 405. The top 10 DNS providers (by broken domain count) are: 58 axc.nl 39 infracom.nl 22 registrar-servers.com 19 loopia.se 19 active24.cz 16 forpsi.net 12 jsr-it.nl 12 cas-com.net 9 ovh.net 9 ignum.com Around 100 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. The number of domains that at some point were listed in Gmail's transparency report is 95 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these 44 are in the most recent report: gmx.at lrz.de xworks.net conjur.com.br mail.de asp4all.nl registro.br posteo.de bhosted.nl gmx.ch ruhr-uni-bochum.de overheid.nl open.ch uni-erlangen.de xs4all.nl anubisnetworks.com unitymedia.de domeneshop.no gmx.com web.de debian.org mail.com enron.email freebsd.org trashmail.com octopuce.fr gentoo.org xfinity.com comcast.net ietf.org bund.de dd24.net netbsd.org fau.de gmx.net openssl.org gmx.de hr-manager.net samba.org jpberlin.de t-2.net torproject.org kabelmail.de xs4all.net In September of 2016 I asked a contact at Google to count how many of the domains in the survey received correspondence from multiple Gmail users. Back then the number was 1,827 out of 56k domains. More recently the number is 2,266 out of ~105k domains. I don't have any way to measure how many domains enable DANE outbound but aren't using DNSSEC for their own domain or publishing TLSA records. It is easy to do, just fire up a local validating resolver, adjust /etc/resolv.conf to list only 127.0.0.1 and/or ::1, and add a couple of lines to main.cf. -- Viktor. From trashcan at ellael.org Thu Dec 29 20:31:24 2016 From: trashcan at ellael.org (Michael Grimm) Date: Thu, 29 Dec 2016 20:31:24 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <20160414184215.GM26423@mournblade.imrryr.org> References: <20160414184215.GM26423@mournblade.imrryr.org> Message-ID: <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> On 14 Apr 2016, Viktor Dukhovni wrote: I know, that's an old mail :-) But I have saved it for the time I will be ready to deploy LE certificates. That time has come. > One approach to making sure that DANE TLSA records are less likely > to fail that should work well for sites using CA-issued certificates > is to publish both "3 1 1" and "2 1 1" TLSA records: > > mx.example. IN TLSA 3 1 1 > mx.example. IN TLSA 2 1 1 [?] > In particular, this is the best practice with Let's Encrypt > issued SMTP server certificates, as explained in: > > https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ First of all I do have to admit that I am lacking knowledge when it comes to certificates, in general. Sofar, I got along with selfsigned certificates that I did generate with the help of all those numerous howtos one can find. It worked. If I do remember correctly, and if I do understand your conclusions in other mails correctly, long lasting selfsigned certificates plus periodically rotated TLSAs are still a good basis to run a secured mailserver at port 25. (FYI: I am using opendnssec for rotating every 3 month.) After having read this best practice document, I am still hesitant to deploy a LE certificate to my mailserver's domain, because I do not understand all the implications, yet. Thus I would like to raise some newbie questions regarding the following project: domain: example.org mailserver: mx.example.org with TLSA 3 1 1 IMAP server: mail.example.org webserver: www.example.org #) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. #) .. and forget about the issues mentioned above? #) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead? Excuses in advance if this are silly questions, but as I mentioned above, I am lacking skills w.r.t. certificates. Thanks un advance and regards, Michael From ietf-dane at dukhovni.org Thu Dec 29 20:47:28 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Dec 2016 14:47:28 -0500 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> Message-ID: > On Dec 29, 2016, at 2:31 PM, Michael Grimm wrote: > >> In particular, this is the best practice with Let's Encrypt >> issued SMTP server certificates, as explained in: >> >> https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ > > First of all I do have to admit that I am lacking knowledge when it comes to certificates, in general. Sofar, I got along with selfsigned certificates that I did generate with the help of all those numerous howtos one can find. It worked. See also: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 > If I do remember correctly, and if I do understand your conclusions in other mails correctly, long lasting selfsigned certificates plus periodically rotated TLSAs are still a good basis to run a secured mailserver at port 25. (FYI: I am using opendnssec for rotating every 3 month.) Yes, you're mostly better off self-signed on port 25. > After having read this best practice document, I am still hesitant to deploy a LE certificate to my mailserver's domain, because I do not understand all the implications, yet. LE means automatic rotation of the cert (by default with a new key) approximately every 90 days. That can mean that you also need to implement unattended rotation of your TLSA records, but I think it is simpler to use a stable key-pair, which is rotated less frequently, and interactively. Using a "3 1 1" + "2 1 1" combination simplifies the rotation procedure. > Thus I would like to raise some newbie questions regarding the following project: > > domain: example.org > mailserver: mx.example.org with TLSA 3 1 1 > IMAP server: mail.example.org > webserver: www.example.org > > #) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. Certainly if you use different hostnames "mx.example.com", ... "www.example.com" as above. > #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. Of course. > #) .. and forget about the issues mentioned above? Yes. Though you may need an LE certificate for the submission service, depending on which clients are doing that. (Mobile phones tend to be difficult to configure for pinned non-CA trust). > #) Or should I strictly separate my mailserver from the rest by means > of distinct domains, instead? Hostnames under a common domain should be fine. Mind you, I've no experience actually using LE (at present), but I can't imagine that it would be difficult to obtain separate certificates for various names under a common domain. -- Viktor. From patrickdk at patrickdk.com Thu Dec 29 20:56:33 2016 From: patrickdk at patrickdk.com (Patrick Domack) Date: Thu, 29 Dec 2016 14:56:33 -0500 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> Message-ID: <20161229145633.Horde.KeUSDmCDb0SXcZqFPAdX9L_@mail.patrickdk.com> Quoting Michael Grimm : > On 14 Apr 2016, Viktor Dukhovni wrote: > > I know, that's an old mail :-) But I have saved it for the time I > will be ready to deploy LE certificates. That time has come. > >> One approach to making sure that DANE TLSA records are less likely >> to fail that should work well for sites using CA-issued certificates >> is to publish both "3 1 1" and "2 1 1" TLSA records: >> >> mx.example. IN TLSA 3 1 1 >> mx.example. IN TLSA 2 1 1 > [?] > > #) Would it be possible to get *two* distinct LE certificates, one > for the IMAP and one for the webserver .. > #) .. and simultaneously *keep* my selfsigned certificate for the > the mailserver .. > #) .. and forget about the issues mentioned above? > > #) Or should I strictly separate my mailserver from the rest by > means of distinct domains, instead? You can get multiple certificates, I have several myself in a single domain, and so this same thing. I am using an LE certificate for my DANE TLSA records, and I do have the auto-rotation script update the TLSA entry. While this is as simple as it sounds, dnssec makes it more complicated. You have to remember your dns ttl and and dnssec rrsig ttl and rrsig expiration for the given entry. I have switched to using dns slave servers and in my implementation that means dnssec rrsig values are signed valid for a week, so I don't push out the new certificate from LE, till two weeks after I added the TLSA dns record, to be safe. The only issue I have had with selfsigned certs is that some mailservers will not send you email if you use one, since the sender has turned on certificate verification, and it will not fail back to non-encrypted to send email. This is mainly a misconfig on their part, but it matters if you want email from them. This has been very minimal impact, but I have seen it a few times. From trashcan at ellael.org Thu Dec 29 21:41:57 2016 From: trashcan at ellael.org (Michael Grimm) Date: Thu, 29 Dec 2016 21:41:57 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> Message-ID: <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> On 29 Dec 2016, at 20:47, Viktor Dukhovni wrote: > On Dec 29, 2016, at 2:31 PM, Michael Grimm wrote: >> First of all I do have to admit that I am lacking knowledge when it comes to certificates, in general. Sofar, I got along with selfsigned certificates that I did generate with the help of all those numerous howtos one can find. It worked. > > See also: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 Thanks for that link. >> If I do remember correctly, and if I do understand your conclusions in other mails correctly, long lasting selfsigned certificates plus periodically rotated TLSAs are still a good basis to run a secured mailserver at port 25. (FYI: I am using opendnssec for rotating every 3 month.) > > Yes, you're mostly better off self-signed on port 25. Ok. Then I will stick to that for the time being. >> After having read this best practice document, I am still hesitant to deploy a LE certificate to my mailserver's domain, because I do not understand all the implications, yet. > > LE means automatic rotation of the cert (by default with a new key) > approximately every 90 days. That can mean that you also need to > implement unattended rotation of your TLSA records, but I think it > is simpler to use a stable key-pair, which is rotated less frequently, > and interactively. Using a "3 1 1" + "2 1 1" combination simplifies > the rotation procedure. Ok. But that will come to human intervention. And that is something I do want to avoid. Although I am only hosting a handful users, my services sometimes do need to run unattended for some weeks (being abroad job-related, vacations, and such). Thus, I have been looking for a solution that works automatically like opendnssec. But that is not available for the combination of DANE and LE certificates. >> Thus I would like to raise some newbie questions regarding the following project: >> >> domain: example.org >> mailserver: mx.example.org with TLSA 3 1 1 >> IMAP server: mail.example.org >> webserver: www.example.org >> >> #) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. > > Certainly if you use different hostnames "mx.example.com", ... "www.example.com" as above. > >> #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. > > Of course. Perfect. >> #) .. and forget about the issues mentioned above? > > Yes. Though you may need an LE certificate for the submission > service, depending on which clients are doing that. (Mobile > phones tend to be difficult to configure for pinned non-CA trust). Ouch! Thanks, but I completely overlooked that issue. Well, I do have to dig into postfix' documentation more thoroughly than I during the last minutes. All my users and myself are using Apple's Mail.app (bench and mobile), and myself roundcube once in a while. Those clients work well in this regard, until today. That said, and still tending to avoid LE on port 25, I will look for a solution that allows me to use a LE certificate for submission and a selfsigned certificate for port 25 services. As I am running FreeBSD and every service (group) runs in it's distinct jail, the following possible solutions come into my mind (untested): #) two instances of postfix on different domain names, one for 25 and one for 587 #) looking for a functionality in postfix that allows for different certificates for 25 and 587 >> #) Or should I strictly separate my mailserver from the rest by means >> of distinct domains, instead? > > Hostnames under a common domain should be fine. Perfect. Thanks for your valuable feedback. I will go for distinct LE certificates for hostnames (mail, www) and stick with selfsigned certificates for port 25. And then I will look for a solution of separating 25 and 587 services. But that is presumably rather OT for this ML. Thanks and with kind regards, Michael From trashcan at ellael.org Thu Dec 29 21:53:05 2016 From: trashcan at ellael.org (Michael Grimm) Date: Thu, 29 Dec 2016 21:53:05 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <20161229145633.Horde.KeUSDmCDb0SXcZqFPAdX9L_@mail.patrickdk.com> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <20161229145633.Horde.KeUSDmCDb0SXcZqFPAdX9L_@mail.patrickdk.com> Message-ID: <3C618CB9-84A0-41C9-82F9-67EFEA5A8E53@ellael.org> On 29 Dec 2016, at 20:56, Patrick Domack wrote > Quoting Michael Grimm : >> #) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. >> #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. >> #) .. and forget about the issues mentioned above? >> >> #) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead? > > You can get multiple certificates, I have several myself in a single domain, and so this same thing. Thanks for your feedback. Then I will gor for that. > I am using an LE certificate for my DANE TLSA records, and I do have the auto-rotation script update the TLSA entry. While this is as simple as it sounds, dnssec makes it more complicated. > > You have to remember your dns ttl and and dnssec rrsig ttl and rrsig expiration for the given entry. I have switched to using dns slave servers and in my implementation that means dnssec rrsig values are signed valid for a week, so I don't push out the new certificate from LE, till two weeks after I added the TLSA dns record, to be safe. See my answers to Viktor. I am very hesitant when it comes to human intervention. Thus, I will avoid it. > The only issue I have had with selfsigned certs is that some mailservers will not send you email if you use one, since the sender has turned on certificate verification, and it will not fail back to non-encrypted to send email. This is mainly a misconfig on their part, but it matters if you want email from them. This has been very minimal impact, but I have seen it a few times. I haven't run into that issue, yet, luckily. If that will happen to my users, I will have to take the burden and apply LE certificates for port 25 as well. But until that time, I will avoid human intervention into a process where two autorotation tools go for "incompatible" tasks :-) Or is there one single tool dealing with DNSSEC, TLSA rotation, and LE upgrades on the market? Thank you for your valuable input and with kind regards, Michael From patrickdk at patrickdk.com Thu Dec 29 21:56:52 2016 From: patrickdk at patrickdk.com (Patrick Domack) Date: Thu, 29 Dec 2016 15:56:52 -0500 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <3C618CB9-84A0-41C9-82F9-67EFEA5A8E53@ellael.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <20161229145633.Horde.KeUSDmCDb0SXcZqFPAdX9L_@mail.patrickdk.com> <3C618CB9-84A0-41C9-82F9-67EFEA5A8E53@ellael.org> Message-ID: <20161229155652.Horde.8_AI_39Cdh66CCbnBvIXZRS@mail.patrickdk.com> Quoting Michael Grimm : > On 29 Dec 2016, at 20:56, Patrick Domack wrote >> Quoting Michael Grimm : > > >>> #) Would it be possible to get *two* distinct LE certificates, one >>> for the IMAP and one for the webserver .. >>> #) .. and simultaneously *keep* my selfsigned certificate for the >>> the mailserver .. >>> #) .. and forget about the issues mentioned above? >>> >>> #) Or should I strictly separate my mailserver from the rest by >>> means of distinct domains, instead? >> >> You can get multiple certificates, I have several myself in a >> single domain, and so this same thing. > > Thanks for your feedback. Then I will gor for that. > >> I am using an LE certificate for my DANE TLSA records, and I do >> have the auto-rotation script update the TLSA entry. While this is >> as simple as it sounds, dnssec makes it more complicated. > >> >> You have to remember your dns ttl and and dnssec rrsig ttl and >> rrsig expiration for the given entry. I have switched to using dns >> slave servers and in my implementation that means dnssec rrsig >> values are signed valid for a week, so I don't push out the new >> certificate from LE, till two weeks after I added the TLSA dns >> record, to be safe. > > See my answers to Viktor. I am very hesitant when it comes to human > intervention. Thus, I will avoid it. > >> The only issue I have had with selfsigned certs is that some >> mailservers will not send you email if you use one, since the >> sender has turned on certificate verification, and it will not fail >> back to non-encrypted to send email. This is mainly a misconfig on >> their part, but it matters if you want email from them. This has >> been very minimal impact, but I have seen it a few times. > > I haven't run into that issue, yet, luckily. If that will happen to > my users, I will have to take the burden and apply LE certificates > for port 25 as well. But until that time, I will avoid human > intervention into a process where two autorotation tools go for > "incompatible" tasks :-) Or is there one single tool dealing with > DNSSEC, TLSA rotation, and LE upgrades on the market? You just add it as part of your certificate update script. Just like you would have it bind a call to update like apache for certificate pinning, you have it call nsupdate to add the new tlsa record into your dns server. From ietf-dane at dukhovni.org Thu Dec 29 22:01:29 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Dec 2016 16:01:29 -0500 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> Message-ID: > On Dec 29, 2016, at 3:41 PM, Michael Grimm wrote: > >> Using a "3 1 1" + "2 1 1" combination simplifies >> the rotation procedure. > > Ok. But that will come to human intervention. And that is something I do > want to avoid. Although I am only hosting a handful users, my services > sometimes do need to run unattended for some weeks (being abroad > job-related, vacations, and such). Thus, I have been looking for > a solution that works automatically like opendnssec. But that is > not available for the combination of DANE and LE certificates. The human intervention is not constrained to happen at any particular time at which you may be unavailable. Rather your certificate continues to be *automatically* renewed with the same underlying key-pair indefinitely. At such time as you *choose* to perform key rotation, you run a suitable script to generate new keys, obtain a new cert, deploy it, update the DNS "TLSA 3 1 1" record and check that everything is in order. Then you can let the automated tools take it from there for some indefinite new period. >>> #) .. and forget about the issues mentioned above? >> >> Yes. Though you may need an LE certificate for the submission >> service, depending on which clients are doing that. (Mobile >> phones tend to be difficult to configure for pinned non-CA trust). > > Ouch! Thanks, but I completely overlooked that issue. > > Well, I do have to dig into postfix' documentation more thoroughly than I during the last minutes. All my users and myself are using Apple's Mail.app (bench and mobile), and myself roundcube once in a while. Those clients work well in this regard, until today. The "smtpd_tls_cert_file" and "smtpd_tls_key_file" settings can take overrides in the master.cf submission entry. > #) looking for a functionality in postfix that allows for different certificates for 25 and 587 No need for a second instance just for separate submission certs. The folks at https://mailinabox.email/ have automated LE certificate management and key rotation. In my survey I see repeated successful TLSA record and certificate rollovers for domains running that stack. I continue to be impressed by their attention to detail. The mailinabox MX hosts represent 526 out of of ~2300 MX hosts with working TLSA records, so their stack is a noticeably large fraction of the deployed base (by server count, the hosting providers of course dominate by domain count). -- Viktor. From trashcan at ellael.org Thu Dec 29 22:12:51 2016 From: trashcan at ellael.org (Michael Grimm) Date: Thu, 29 Dec 2016 22:12:51 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <20161229155652.Horde.8_AI_39Cdh66CCbnBvIXZRS@mail.patrickdk.com> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <20161229145633.Horde.KeUSDmCDb0SXcZqFPAdX9L_@mail.patrickdk.com> <3C618CB9-84A0-41C9-82F9-67EFEA5A8E53@ellael.org> <20161229155652.Horde.8_AI_39Cdh66CCbnBvIXZRS@mail.patrickdk.com> Message-ID: <220947B4-A770-4359-9828-421A9D6F5429@ellael.org> On 29 Dec 2016, at 21:56, Patrick Domack wrote: > > Quoting Michael Grimm : >> But until that time, I will avoid human intervention into a process where two autorotation tools go for "incompatible" tasks :-) Or is there one single tool dealing with DNSSEC, TLSA rotation, and LE upgrades on the market? > > You just add it as part of your certificate update script. > > Just like you would have it bind a call to update like apache for certificate pinning, you have it call nsupdate to add the new tlsa record into your dns server. Well, that sound much better than assumed. But I will test it in a test jail, first. Thank you, again, and with kind regards, Michael From trashcan at ellael.org Thu Dec 29 22:24:14 2016 From: trashcan at ellael.org (Michael Grimm) Date: Thu, 29 Dec 2016 22:24:14 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> Message-ID: <053EFC12-0BB3-4C11-90B2-AED8E903BF99@ellael.org> On 29 Dec 2016, at 22:01, Viktor Dukhovni wrote: > On Dec 29, 2016, at 3:41 PM, Michael Grimm wrote: >> Ok. But that will come to human intervention. > > The human intervention is not constrained to happen at any particular > time at which you may be unavailable. Rather your certificate continues > to be *automatically* renewed with the same underlying key-pair indefinitely. > > At such time as you *choose* to perform key rotation, you run a suitable > script to generate new keys, obtain a new cert, deploy it, update the DNS > "TLSA 3 1 1" record and check that everything is in order. Then you can > let the automated tools take it from there for some indefinite new period. Oh! I do have do admit then, that I didn't understand that approach by combining two different TLSA "types". I believed, that I wouldn't have the "supervision" about *when* to intervene manually. As I mentioned before, I am having difficulties in understanding the complete picture regarding this process. But, your and Patrick's feedback will let me start investigating the process of automatic LE certificate and DNSSEC/TLSA renewals in a test jail. I believe that I will understand it better by doing :-) >>> >> Well, I do have to dig into postfix' documentation more thoroughly than I during the last minutes. All my users and myself are using Apple's Mail.app (bench and mobile), and myself roundcube once in a while. Those clients work well in this regard, until today. > > The "smtpd_tls_cert_file" and "smtpd_tls_key_file" settings can > take overrides in the master.cf submission entry. I knew that you knew it :-) Thanks. I will test that. >> #) looking for a functionality in postfix that allows for different certificates for 25 and 587 > > No need for a second instance just for separate submission certs. Again. Thanks for your feedback. I will test this. > The folks at https://mailinabox.email/ have automated LE certificate > management and key rotation. In my survey I see repeated successful > TLSA record and certificate rollovers for domains running that stack. > I continue to be impressed by their attention to detail. > > The mailinabox MX hosts represent 526 out of of ~2300 MX hosts with > working TLSA records, so their stack is a noticeably large fraction > of the deployed base (by server count, the hosting providers of course > dominate by domain count). Ok, it *can* be done (by professionals :-) ). Thanks and with kind regards, Michael From ietf-dane at dukhovni.org Thu Dec 29 22:29:26 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Dec 2016 16:29:26 -0500 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <053EFC12-0BB3-4C11-90B2-AED8E903BF99@ellael.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> <053EFC12-0BB3-4C11-90B2-AED8E903BF99@ellael.org> Message-ID: <4F75B393-3529-4ABB-AF28-3A55B79EE225@dukhovni.org> > > On Dec 29, 2016, at 4:24 PM, Michael Grimm wrote: > >> The folks at https://mailinabox.email/ have automated LE certificate >> management and key rotation. In my survey I see repeated successful >> TLSA record and certificate rollovers for domains running that stack. >> I continue to be impressed by their attention to detail. >> >> The mailinabox MX hosts represent 526 out of of ~2300 MX hosts with >> working TLSA records, so their stack is a noticeably large fraction >> of the deployed base (by server count, the hosting providers of course >> dominate by domain count). > > Ok, it *can* be done (by professionals :-) ). Perhaps "dedicated volunteers" is a more apt description. You might find that using their software is simpler than "do it yourself" (DIY). If all you want is a low-effort working mailserver for a personal domain, check out the mailinabox.email option. -- Viktor. From trashcan at ellael.org Thu Dec 29 22:47:01 2016 From: trashcan at ellael.org (Michael Grimm) Date: Thu, 29 Dec 2016 22:47:01 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <4F75B393-3529-4ABB-AF28-3A55B79EE225@dukhovni.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> <053EFC12-0BB3-4C11-90B2-AED8E903BF99@ellael.org> <4F75B393-3529-4ABB-AF28-3A55B79EE225@dukhovni.org> Message-ID: On 29 Dec 2016, at 22:29, Viktor Dukhovni wrote: > >> On Dec 29, 2016, at 4:24 PM, Michael Grimm wrote: >>> The folks at https://mailinabox.email/ have automated LE certificate >>> management and key rotation. >> >> Ok, it *can* be done (by professionals :-) ). > > Perhaps "dedicated volunteers" is a more apt description. You might > find that using their software is simpler than "do it yourself" (DIY). > If all you want is a low-effort working mailserver for a personal > domain, check out the mailinabox.email option. No, no, this is my hobby, and I will not let go :-) I am confident that I will get LE certificates running. I only had had the fear that mailing might break while being abroad, because manual intervention might have been missed during such a period in time. Thanks and regards, Michael From ietf-dane at dukhovni.org Thu Dec 29 22:56:58 2016 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Dec 2016 16:56:58 -0500 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> <053EFC12-0BB3-4C11-90B2-AED8E903BF99@ellael.org> <4F75B393-3529-4ABB-AF28-3A55B79EE225@dukhovni.org> Message-ID: <6AED672E-845F-4C9E-B273-6E10981251B9@dukhovni.org> > On Dec 29, 2016, at 4:47 PM, Michael Grimm wrote: > > > I only had had the fear that mailing might break while being abroad, > because manual intervention might have been missed during such a > period in time. A reasonable concern, a large fraction of LE users botch the cert renewal interaction with TLSA one or more times before they eventually figure out how to do it right. If you: * Configure LE cert renewal to NOT replace your key, just issue a new certificate for the *same* key as before: https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 * Publish a "3 1 1" TLSA record for the stable public key. Then LE certificate renewal require no DNS changes, and can proceed in an automated manner via their tools. From time to time, you might decide that your key has been lying around on your server too long, and may now be compromised. Then you create a new key-pair and do LE renewal with that key instead. You then can either go with the process outlined in: http://tools.ietf.org/html/rfc7671#section-8.1 Or, if you trust LE to not issue certificates for your domain to strangers (the verification process for DV certificates is not especially strong), you can use the "3 1 1 + 2 1 1" approach to simplify the deployment process. -- Viktor. From trashcan at ellael.org Fri Dec 30 11:53:21 2016 From: trashcan at ellael.org (Michael Grimm) Date: Fri, 30 Dec 2016 11:53:21 +0100 Subject: Best practice TLSA RRs for CA-issued certs In-Reply-To: <6AED672E-845F-4C9E-B273-6E10981251B9@dukhovni.org> References: <20160414184215.GM26423@mournblade.imrryr.org> <69E4F6C2-EBBF-48C1-BA63-1A47ED24F5A1@ellael.org> <666C35D5-7346-4C65-88E8-F655BF3107CF@ellael.org> <053EFC12-0BB3-4C11-90B2-AED8E903BF99@ellael.org> <4F75B393-3529-4ABB-AF28-3A55B79EE225@dukhovni.org> <6AED672E-845F-4C9E-B273-6E10981251B9@dukhovni.org> Message-ID: On 29 Dec 2016, at 22:56, Viktor Dukhovni wrote: > If you: > > * Configure LE cert renewal to NOT replace your key, just issue a new > certificate for the *same* key as before: > > https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766 > > * Publish a "3 1 1" TLSA record for the stable public key. > > Then LE certificate renewal require no DNS changes, and can proceed in > an automated manner via their tools. Thank you for your clarification that *no DNS changes are required*, .. > From time to time, you might decide that your key has been lying around on > your server too long, and may now be compromised. Then you create a new > key-pair and do LE renewal with that key instead. You then can either > go with the process outlined in: > > http://tools.ietf.org/html/rfc7671#section-8.1 .. *unless* I manually go for a new key. Perfect. That is a procedure I can live with, and I will follow that approach, then. I'd like to thank you both for your help in understanding what will be the upcoming steps when implementing LE certificates. With kind regards and a Happy New Year, Michael