From ietf-dane at dukhovni.org Fri Feb 10 21:25:41 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 Feb 2017 20:25:41 +0000 Subject: Don't forget to add TLSA records for black-hole MX hosts Message-ID: <20170210202541.GZ28349@mournblade.imrryr.org> Some domains with DANE-TLSA records for their primary MX hosts neglect to publish DANE TLSA for secondary and/or "black-hole" (spam magnet) MX hosts. Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA records (and SMTP connections to that host would time out). This gives an active on-path MiTM attacker opportunity to block connections to the working MX hosts, and accept unauthenticated connections to the black-hole MX host. After they were notified of the problem, they made changes, and now we see TLSA records associated with all the MX hosts, including "bh.nic.cz": nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1 nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1 nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1 ; mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1 mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1 _25._tcp.mail.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 ; mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1 mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; NOERROR AD=1 _25._tcp.mx.nic.cz. IN TLSA 3 1 1 aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; NOERROR AD=1 ; bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1 bh.nic.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.bh.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 I've not yet nagged "iis.se" or "wia.cz", and there we see that only one of the two MX hosts has a TLSA record: iis.se. IN MX 5 mx1.iis.se. ; NOERROR AD=1 iis.se. IN MX 5 mx2.iis.se. ; NOERROR AD=1 ; mx1.iis.se. IN A 91.226.36.35 ; NOERROR AD=1 mx1.iis.se. IN AAAA 2a00:801:f0:106::35 ; NOERROR AD=1 _25._tcp.mx1.iis.se. IN TLSA 3 1 1 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; NOERROR AD=1 ; mx2.iis.se. IN A 91.226.37.39 ; NOERROR AD=1 mx2.iis.se. IN AAAA 2001:67c:124c:2007::39 ; NOERROR AD=1 _25._tcp.mx2.iis.se. IN TLSA ? ; NXDOMAIN AD=1 wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1 wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1 ; antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1 antispam.wia.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.antispam.wia.cz. IN TLSA 3 1 1 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; NOERROR AD=1 ; bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1 bntispam.wia.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1 While during initial deployment it is natural to proceed incrementally and add TLSA records to one MX host at a time, and test thoroughly before moving on to the rest, the end-state should be to publish TLSA records for all MX hosts, not a proper subset. -- Viktor. From alex.dupuy at mac.com Mon Feb 13 14:40:35 2017 From: alex.dupuy at mac.com (Alexander Dupuy) Date: Mon, 13 Feb 2017 08:40:35 -0500 Subject: Don't forget to add TLSA records for black-hole MX hosts In-Reply-To: <20170210202541.GZ28349@mournblade.imrryr.org> References: <20170210202541.GZ28349@mournblade.imrryr.org> Message-ID: <3107E22F-A11B-4E7D-9C3E-071636466017@mac.com> The wonderful Internet.nl website and e-mail security and standards compliance checker, which was the first thing I thought of when I saw this message from Viktor, doesn?t currently check for TLSA records for MX hosts (although it does check for DNSSEC on the zones of MX hostnames, e.g. https://internet.nl/mail/dns-example.info/results# ). It would be wonderful if that functionality could be added in a future update to their site. Does NLnet Labs , which develops the software for this great checking tool, have a public repository for it? If so, I would be happy to submit a pull-request or patch to add that functionality. @alex p.s. could someone at Internet.nl please add Verisign Public DNS (https://www.verisign.com/en_US/security-services/public-dns/index.xhtml ) to the list of DNSSEC-validating public DNS services at https://internet.nl/faqs/dnssec/? They are the first major public DNS service after Google Public DNS to provide this feature, present from day one of their service (even though they don?t mention it), and they should be listed. > On 2017-02-10, at 15:25, Viktor Dukhovni wrote: > > > Some domains with DANE-TLSA records for their primary MX hosts > neglect to publish DANE TLSA for secondary and/or "black-hole" > (spam magnet) MX hosts. > > Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA > records (and SMTP connections to that host would time out). This > gives an active on-path MiTM attacker opportunity to block connections > to the working MX hosts, and accept unauthenticated connections to > the black-hole MX host. After they were notified of the problem, > they made changes, and now we see TLSA records associated with > all the MX hosts, including "bh.nic.cz": > > nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1 > nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1 > nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1 > ; > mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1 > mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1 > _25._tcp.mail.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 > ; > mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1 > mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; NOERROR AD=1 > _25._tcp.mx.nic.cz. IN TLSA 3 1 1 aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; NOERROR AD=1 > ; > bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1 > bh.nic.cz. IN AAAA ? ; NODATA AD=1 > _25._tcp.bh.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 > > I've not yet nagged "iis.se" or "wia.cz", and there we see that > only one of the two MX hosts has a TLSA record: > > iis.se. IN MX 5 mx1.iis.se. ; NOERROR AD=1 > iis.se. IN MX 5 mx2.iis.se. ; NOERROR AD=1 > ; > mx1.iis.se. IN A 91.226.36.35 ; NOERROR AD=1 > mx1.iis.se. IN AAAA 2a00:801:f0:106::35 ; NOERROR AD=1 > _25._tcp.mx1.iis.se. IN TLSA 3 1 1 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; NOERROR AD=1 > ; > mx2.iis.se. IN A 91.226.37.39 ; NOERROR AD=1 > mx2.iis.se. IN AAAA 2001:67c:124c:2007::39 ; NOERROR AD=1 > _25._tcp.mx2.iis.se. IN TLSA ? ; NXDOMAIN AD=1 > > wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1 > wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1 > ; > antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1 > antispam.wia.cz. IN AAAA ? ; NODATA AD=1 > _25._tcp.antispam.wia.cz. IN TLSA 3 1 1 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; NOERROR AD=1 > ; > bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1 > bntispam.wia.cz. IN AAAA ? ; NODATA AD=1 > _25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1 > > While during initial deployment it is natural to proceed incrementally > and add TLSA records to one MX host at a time, and test thoroughly > before moving on to the rest, the end-state should be to publish > TLSA records for all MX hosts, not a proper subset. > > -- > Viktor. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP URL: From john at klam.ca Sun Feb 19 19:20:52 2017 From: john at klam.ca (John Allen) Date: Sun, 19 Feb 2017 13:20:52 -0500 Subject: Letsencrypt & TLSA - automation Message-ID: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> Attached is a bash script that I am developing to automate the generation of TLSA records from Letsencrypt certificates. the script is called from the certbot renew hook, it can also be run stand alone - Certbot_TLSAgen path-to-certificate "space separated list of domains included in cert" It seems to work, but would some kind sole take a look and where I have or are about to screw up. Any suggestions as to how to get the output into my DNS (Bind9) preferably without using nsupdate. I am not keen on nsupdate as it makes a mess of the zone files, which I use as documentation for my DNS. Has anybody heard of a electronic "one time pad" system. TIA JohnA -------------- next part -------------- #!/bin/bash #===================================================================================================================== # # Copyright (c) 2017 John L. Allen # # This program is free software: you can redistribute it and/or modify it under the terms of the # GNU General Public License as published by the Free Software Foundation, either version 3 of the License, # or (at your option) any later version. # # This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; # without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see . # #===================================================================================================================== declare -a TLSA_Services=( smtp imap submission sieve dav davical https ) # An arrrayof services for which TLSA might be needed # these two variables are ???? Certbot_Lineage= # path to the certbot generated cert ...(RENEWED_LINEAGE or $1) declare -a Certbot_Domains # An array into which RENEWED_DOMAINS or $2 Domains are split # default values #TLSA_File_Path="/etc/bind/tlsa/" # where do you want to put the TLSA records, default values TLSA_File_Path="./tlsa_test/" # where do you want to put the TLSA records, default values - during testing TLSA_Filename_Base="tlsa" # base filename for the TLSA records - generated as base_filename.sequence_number TLSA_TTL=3600 # TLSA DNS record TTL TLSA_Usage=3 # TLSA usage TLSA_Selector=1 # TLSA selector TLSA_Type=1 # TLSA type # #===================================================================================================================== #===================Message output function - will need changing to output multi language message===================== function error_message() { echo $1 1>&2 exit 1 } #===================================================================================================================== #================ Check of either the Certbot set environment variables or the command line paramater================= #================ depending upon how this script is invocked ================= #===================================================================================================================== function Check_Env_Variables() { # Has command line parameter 1 or the environment variable RENEWED_LINEAGE been set. # The Command line parameter overides the environment variable [[ -z $RENEWED_LINEAGE ]] && Certbot_Lineage=$1 || Certbot_Lineage=$RENEWED_LINEAGE if [[ -z $Certbot_Lineage ]]; then error_code= $(error_message "Command line parameter 1 or the evironment variable \"RENEWED_LINEAGE\" was not set, exiting") elif ! [[ -d $Certbot_Lineage ]]; then error_code= $(error_message "Command line parameter 1 or the evironment variable \"RENEWED_LINEAGE\" is not a directory, exiting") fi # Has command line parameter 2 or the environment variable RENEWED_DOMAINS been set. # The Command line parameter overides the environment variable # If more than one domain is specified they are expected to be in the form of a space seperated list [[ -z $RENEWED_DOMAINS ]] && Certbot_Domains=( $2 ) || Certbot_Domains=( ${RENEWED_DOMAINS} ) if [[ ${#Certbot_Domains[@]} -le 0 ]]; then error_code=$(error_message "Command line parameter 2 or the evironment variable \"RENEWED_DOMAINS\" was not set, exiting") fi # Check that the TLSA_File_Path is the location (directory) where files containing the generated TLSA records will be put # if ! [ -d $TLSA_File_Path ]; then error_code=$(error_message "the directory $TLSA_File_Path does not exist, please specify where the generated records are to be stored") fi # Check that the TLSA filename base has been set. # The filename base is used to generate actual filenames in the form of base.sequence # if [ -z "$TLSA_Filename_Base" ]; then error_code=$(error_message "Please specify a base filename into which the generated TLSA records can be placed") fi return $error_code } #===================================================================================================================== #=======Set the output file name, including path. #=======The filename is derived from TLSA_Filename_Base plus a generated serial number suffix zzz=" " function Set_Output_Destination() { count=$( ls -1 $1 | wc -l ) name=$(printf "%s%s.%04d" "$1" "$2" "$count") while [ -a $name ]; do count=$(( $count+1)) name=$(printf "%s%s.%04d" "$1" "$2" "$count") done echo $name } #===================================================================================================================== #******************************************************************************************************************** #******************************************************************************************************************** # THe following functions were stolen from Viktor Dukhovni's tlsagen #******************************************************************************************************************** #******************************************************************************************************************** #===================================================================================================================== extract() { case "$1" in 0) openssl x509 -in "$2" -outform DER;; 1) openssl x509 -in "$2" -noout -pubkey | openssl pkey -pubin -outform DER;; esac } digest() { case "$1" in 0) cat;; 1) openssl dgst -sha256 -binary;; 2) openssl dgst -sha512 -binary;; esac } Set_TLSA_Usage() { case "$(echo $1 | tr '[A-Z]' '[a-z]')" in 0|pkix-[ct]a) TLSA_usage=0;; 1|pkix-ee) TLSA_usage=1;; 2|dane-[ct]a) TLSA_usage=2;; 3|dane-ee) TLSA_usage=3;; *) error "Invalid certificate usage: $1";; esac } Set_TLSA_Selector() { case "$(echo $1 | tr '[A-Z]' '[a-z]')" in 0|cert) TLSA_selector=0;; 1|spki|pkey) TLSA_selector=1;; *) error "Invalid selector: $1";; esac } Set_TLSA_Type() { case "$(echo $1 | tr '[A-Z]' '[a-z]')" in 0|full) TLSA_Type=0;; 1|sha2-256|sha256|sha-256) TLSA_Type=1;; 2|sha2-512|sha512|sha-512) TLSA_Type=2;; *) error "Invalid matching type: $1";; esac } #===================================================================================================================== #===================================================================================================================== # as we cannot pass and parameters when this is called from the certbot renew hooks # we will have to put them somewhere else, # Defailt for general parameters # if [ -f /etc/default/Cerbot_TLSAgen.cf ]; then . /etc/default/Cerbot_TLSAgen.cf; fi Check_Env_Variables "$1" "$2" # If we are running as a command then these two should be set, if not certbot environment variables should be [[ $? != 0 ]] && exit # ooops! exit. this needs some improvement #******needs testing # Certbot_Lineage should now be set, so pick up any cert based paramamters from the ".../live/certname" directory # if [ -f ${Certbot_Lineage}Certbot_TLSAgen.cf ]; then . ${Certbot_Lineage}Certbot_TLSAgen.cf; fi TLSA_Record_Store=$(Set_Output_Destination $TLSA_File_Path $TLSA_Filename_Base) # generate the output file location Path + generate filename [[ $? != 0 ]] && exit # ooops! exit. this needs some improvement TLSA_Digest=$( extract $TLSA_Selector ${Certbot_Lineage}cert.pem | digest $TLSA_Type | od -vAn -tx1 | tr -d ' \012' # Generate the TLSA key as a HEX string. As we are dealiing with a single cert do this once exit $(( ${PIPESTATUS[0]} | ${PIPESTATUS[1]} | ${PIPESTATUS[2]} )) ) [[ $? != 0 ]] && exit # ooops! exit. this needs some improvement # for each (sub)domain listed, check to see if it is a service doamin that we might like to have a TLSA record for # for domain in $( seq 0 $((${#Certbot_Domains[@]} -1 )) ); do TLSA_target=${Certbot_Domains[domain]%.} # I am not sure whether the Cerbot list of (sub)domains has a trailing "." TLSA_domain=${TLSA_target#*.} # Hopefully this will strip off the sub-domain part giving me a domain-name + TLD if [[ -z "${TLSA_domain##*.*}" ]]; then # Primitive test - if there is a "." this is likely to be domin + TLD for service in $( seq 0 $((${#TLSA_Services[@]} -1 )) ); do # Do this for each of the services that might us a TLSA record while read srv_priority srv_weight srv_port srv_host; # read the out put of a DIG for a SRV record do if [ ${srv_host%.} == $TLSA_target ]; then # if the host returned by dig = the Cerbot target output a TLSA record printf "_%d._tcp.%s %d IN TLSA %d %d %d %s\n"\ "$srv_port" "$srv_host" "$TLSA_TTL" "$TLSA_Usage" "$TLSA_Selector" "$TLSA_Type" "$TLSA_Digest" >> $TLSA_Record_Store fi done < <(dig SRV _${TLSA_Services[$service]}._tcp.${TLSA_domain} +short) # done # SOA_domain=$TLSA_domain # read soa_ns soa_admin soa_seq soa_t1 soa_t2 soa_t3 soa_t4 < <(dig SOA $SOA_domain +short) fi done From dgouttegattat at incenp.org Sun Feb 19 20:02:28 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 19 Feb 2017 20:02:28 +0100 Subject: Letsencrypt & TLSA - automation In-Reply-To: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> Message-ID: On 02/19/2017 07:20 PM, John Allen wrote: > Any suggestions as to how to get the output into my DNS (Bind9) > preferably without using nsupdate. For what it's worth, my method to insert TLSA records into my zone files is to use some M4 macros. The idea is to "fetch" the digests from the zone file when signing it, instead of "pushing" the digests to the zone file when renewing the certificates. So, my zone file contains something like that: ---8<--- m4_define(SPKI_DGST, `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ openssl rsa -pubin -outform DER | \ openssl dgst -sha256 -binary | \ openssl enc -base64)') _443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert) _25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert) --->8--- (Actually the macro definition is in a separate file which is included in the zone file. But you get the idea.) The file is then processed by `m4 -P` and the resulting zone file is signed by dnssec-signzone. (The manual for GNU M4 contains a warning that M4 can be "fairly addictive" and that its users tend to use it everywhere; I'm afraid that's true.) Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Sun Feb 19 20:23:52 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 19 Feb 2017 14:23:52 -0500 Subject: Letsencrypt & TLSA - automation In-Reply-To: References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> Message-ID: > On Feb 19, 2017, at 2:02 PM, Damien Goutte-Gattat wrote: > > ---8<--- > m4_define(SPKI_DGST, > `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ > openssl rsa -pubin -outform DER | \ > openssl dgst -sha256 -binary | \ > openssl enc -base64)') > > _443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert) > _25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert) > --->8--- Are you sure that base64 works in this context??? The presentation format for TLSA records is hex encoded. I use: hexdump -ve '/1 "%02X"' where you're using "openssl enc -base64" > (The manual for GNU M4 contains a warning that M4 can be "fairly addictive" and that its users tend to use it everywhere; I'm afraid that's true.) Long ago I too was an m4 addict, but then I kicked the habit... :-) That said, this implementation looks sensible. -- Viktor. From dgouttegattat at incenp.org Sun Feb 19 21:17:14 2017 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Sun, 19 Feb 2017 21:17:14 +0100 Subject: Letsencrypt & TLSA - automation In-Reply-To: References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> Message-ID: <26808e3e-9e2d-8518-6844-96d89bdcc728@incenp.org> On 02/19/2017 08:23 PM, Viktor Dukhovni wrote: > Are you sure that base64 works in this context??? The presentation > format for TLSA records is hex encoded. Oups. I re-wrote the macro in my message from memory instead of pasting it from my actual script, and of course I messed up. (Coincidentally, I spent the last few hours writing an introduction to HTTP Public-Key Pinning, which does use base64 encoding.) My real macro is: m4_define(SPKI_DGST, `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ openssl rsa -pubin -outform DER | \ openssl dgst -sha256 | cut -d" " -f2)') Sorry about that, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dane at lists.grepular.com Mon Feb 20 08:25:05 2017 From: dane at lists.grepular.com (Mike Cardwell) Date: Mon, 20 Feb 2017 07:25:05 +0000 Subject: Letsencrypt & TLSA - automation In-Reply-To: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> Message-ID: <20170220072505.GA31299@snake.grepular.com> How do you intend to deal with the DNS caching issues? I.e, that you need to renew the SSL cert and then publish it in the DNS for at least one TTL before actually putting the cert in to production. Mike * on the Sun, Feb 19, 2017 at 01:20:52PM -0500, John Allen wrote: > Attached is a bash script that I am developing to automate the generation of > TLSA records from Letsencrypt certificates. > > the script is called from the certbot renew hook, it can also be run stand > alone - Certbot_TLSAgen path-to-certificate "space separated list of domains > included in cert" > > It seems to work, but would some kind sole take a look and where I have or > are about to screw up. > > > Any suggestions as to how to get the output into my DNS (Bind9) preferably > without using nsupdate. I am not keen on nsupdate as it makes a mess of the > zone files, which I use as documentation for my DNS. > > > Has anybody heard of a electronic "one time pad" system. -- Mike Cardwell https://www.grepular.com OpenPGP Key DF70 D8E5 FBD6 8519 9257 C44C 0DA6 8B1E 1801 A332 XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: Digital signature URL: From john at klam.ca Mon Feb 20 11:49:11 2017 From: john at klam.ca (John Allen) Date: Mon, 20 Feb 2017 05:49:11 -0500 Subject: Letsencrypt & TLSA - automation In-Reply-To: <20170220072505.GA31299@snake.grepular.com> References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> <20170220072505.GA31299@snake.grepular.com> Message-ID: <41af87f9-88b6-df95-e267-e8d0bc22048d@klam.ca> I am not sure, I have used INCLUDE statements in my zone files in the past. But some people don't like them. My thinking is that immediately after a cert update I would include two files current and current -1 (probably using symlinks), after the TTL period has past/expired I would remove current -1. Removing it might mean that I update its symlink to point to an "empty" file. not literal empty but only contains a comment(s)?? Another way, one that to me this feels extremely clumsy and as a result I am not too keen on. Might be to have two copies of the zone file, a working zone file and an operation zone file. The operational zone is created by concatenation of the working file + the current TLSA file + the expiring TLSA file during the TTL period. Still have not worked out how to update the SOA sequence number, bearing in mind that the the Bind zone file is somewhat free form. JohnA From john at klam.ca Mon Feb 20 11:55:58 2017 From: john at klam.ca (John Allen) Date: Mon, 20 Feb 2017 05:55:58 -0500 Subject: Letsencrypt & TLSA - automation In-Reply-To: References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> Message-ID: <247933b9-8c6f-ef72-776a-dd8e877c87da@klam.ca> Is the process to update the serial number automatic? If so care to share. On 2017-02-20 4:04 AM, Casper Gielen wrote: > Op 19-02-17 om 19:20 schreef John Allen: >> Attached is a bash script that I am developing to automate the >> generation of TLSA records from Letsencrypt certificates. >> >> the script is called from the certbot renew hook, it can also be run >> stand alone - Certbot_TLSAgen path-to-certificate "space separated list >> of domains included in cert" >> >> It seems to work, but would some kind sole take a look and where I have >> or are about to screw up. >> >> >> Any suggestions as to how to get the output into my DNS (Bind9) >> preferably without using nsupdate. I am not keen on nsupdate as it makes >> a mess of the zone files, which I use as documentation for my DNS. > It may not be the cleanest method, but I use the INCLUDE statement in my > zones to include snippets of externally maintained information. > > The script I use outputs the required records and I just put it in the > right file and trigger a procedure to update the serial number and > reload Bind. > From cgielen+dane-sys4 at uvt.nl Mon Feb 20 12:50:10 2017 From: cgielen+dane-sys4 at uvt.nl (Casper Gielen) Date: Mon, 20 Feb 2017 12:50:10 +0100 Subject: Letsencrypt & TLSA - automation In-Reply-To: <247933b9-8c6f-ef72-776a-dd8e877c87da@klam.ca> References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> <247933b9-8c6f-ef72-776a-dd8e877c87da@klam.ca> Message-ID: <20936d0d-0e13-4ff6-8fd5-4c58e891d599@uvt.nl> Op 20-02-17 om 11:55 schreef John Allen: > Is the process to update the serial number automatic? If so care to share. Just a tiny and unreliable script that works in my controlled environment where zonefiles use a serial based on the date. I wouldn't recommend using it as is, but I've attached it for inspiration. -- Casper Gielen | LIS UNIX PGP fingerprint = 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7 Universiteit van Tilburg | Postbus 90153, 5000 LE Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl -------------- next part -------------- #!/usr/bin/env bash # # Update serial in a zone file # Casper Gielen, 2016 usage() { echo "usage: update-serial " echo "Updates the serial of a zonefile to the current date + a counter" exit 1 } zonefile="$1" [ -z "$zonefile" ] && usage # FIXME: improve the way we find the serial old=$(awk '/;serial/{print $1}' $zonefile) old_date=${old:0:8} old_count=${old:(-2)} new_date=$(date +%Y%m%d) new_count="00" if [ "$new_date" == "$old_date" ]; then new_count=$(printf "%02d" "$[ 10#$old_count + 1 ]") fi new="${new_date}${new_count}" # FIXME: make sure we change the right line sed -i "s/$old/$new/" $zonefile -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Tue Feb 21 04:38:13 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Feb 2017 22:38:13 -0500 Subject: Letsencrypt & TLSA - automation In-Reply-To: <20170220072505.GA31299@snake.grepular.com> References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> <20170220072505.GA31299@snake.grepular.com> Message-ID: > On Feb 20, 2017, at 2:25 AM, Mike Cardwell wrote: > > How do you intend to deal with the DNS caching issues? I.e, that you > need to renew the SSL cert and then publish it in the DNS for at least > one TTL before actually putting the cert in to production. Indeed this is the key issue. The certificate provided by Let's Encrypt should not be deployed as the live certificate used by the MTA until the DNS TLSA records have been in place for at least a couple of TTLs. Keep in that "TTL" here means not just the TTL for the RRset, but also the refresh time of the zone by any slave servers, since until they obtain fresh data they may be serving stale records with the full data TTL. The simplest approach is to not point your MTA directly at the LE certs, but instead to update the copy used by the MTA once the LE cert and its TLSA digest have been in place sufficiently long... This is complicated, which is why I recommend the "3 1 1" + "2 1 1" approach with a stable public key described in: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444 and also in: https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/ -- Viktor. From dane-users-phil at spodhuis.org Tue Feb 21 05:38:09 2017 From: dane-users-phil at spodhuis.org (Phil Pennock) Date: Tue, 21 Feb 2017 04:38:09 +0000 Subject: Letsencrypt & TLSA - automation In-Reply-To: References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> <20170220072505.GA31299@snake.grepular.com> Message-ID: <20170221043808.GA48769@tower.spodhuis.org> On 2017-02-20 at 22:38 -0500, Viktor Dukhovni wrote: > Indeed this is the key issue. The certificate provided by Let's Encrypt > should not be deployed as the live certificate used by the MTA until the > DNS TLSA records have been in place for at least a couple of TTLs. This is why I just use DANE on the CA certs, with a spare CA entry, so that I don't need to coordinate grace periods around updating DNS on each renewal. For exim.org, it's just LE. I ended up dropping down to just X3 and X4. For my own domains, it's LE and my private CAs. For HPKP where there is a little more room inside the TCP stream and I set longer TTLs, I include a commercial CA too; if everything goes to hell and I end up paying for some certs for a year, I at least have an exit plan. I can add to DNS as-and-when needed. -Phil From ietf-dane at dukhovni.org Tue Feb 21 05:47:28 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Feb 2017 23:47:28 -0500 Subject: Letsencrypt & TLSA - automation In-Reply-To: <20170221043808.GA48769@tower.spodhuis.org> References: <157604c2-732a-488a-9908-c8cb0b6dd9e9@klam.ca> <20170220072505.GA31299@snake.grepular.com> <20170221043808.GA48769@tower.spodhuis.org> Message-ID: <9ACA21DA-EA3F-4F5A-B92C-D27534654ED6@dukhovni.org> > On Feb 20, 2017, at 11:38 PM, Phil Pennock wrote: > > This is why I just use DANE on the CA certs, with a spare CA entry, so > that I don't need to coordinate grace periods around updating DNS on > each renewal. > > For exim.org, it's just LE. I ended up dropping down to just X3 and X4. > > For my own domains, it's LE and my private CAs. Thanks for that note. If one is willing to issue leaf certs from a private CA, that's by far the most robust option for port 25, where having a public trusted CA in the chain is not particularly useful. By all means, use LE on ports 587/465 for submission from mass-market MUAs, but MTAs will either be opportunistic unauthenticated, or verify private EE/private TA certs. I'll probably add some code to Postfix 3.3 to make it easy to create a TA key/cert + EE key/cert issued by said TA. And code to roll these as described in the various messages I keep posting links to. Updating the DNS will require a user-provided hook. -- Viktor. From john at klam.ca Wed Feb 22 23:17:46 2017 From: john at klam.ca (John Allen) Date: Wed, 22 Feb 2017 17:17:46 -0500 Subject: TLSA record TTL values Message-ID: Is the any recommendation as to the TTL for TLSA records? I would imagine fairly short as if the is a problem you want the old ones gone ASAP! John A From ietf-dane at dukhovni.org Wed Feb 22 23:50:03 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Feb 2017 17:50:03 -0500 Subject: TLSA record TTL values In-Reply-To: References: Message-ID: > On Feb 22, 2017, at 5:17 PM, John Allen wrote: > > Is the any recommendation as to the TTL for TLSA records? An hour or less. Depending on how time-sensitive your email is. Keep in mind the refresh time of secondary servers, setting the TTL much below that does not help much. > I would imagine fairly short as if the is a problem you want the old ones gone ASAP! Yes, that's the basic motivation to keep it reasonably short. -- Viktor. From dane-users-phil at spodhuis.org Sat Feb 25 06:05:15 2017 From: dane-users-phil at spodhuis.org (Phil Pennock) Date: Sat, 25 Feb 2017 05:05:15 +0000 Subject: smtpdane testing tool (early alpha) Message-ID: <20170225050514.GA52256@tower.spodhuis.org> Folks, If you have Golang 1.8 (or newer) installed, my "smtpdane" tool might be of interest. mkdir ~/go go get go.pennock.tech/smtpdane There's a README.md with invoking hints, etc. Current git hosting has this visible at: https://github.com/PennockTech/smtpdane I'll repeat the warning at the top of the README.md: } EARLY ALPHA SOFTWARE } } THIS HAS NOT YET BEEN TESTED TO CONFIRM IT FAILS WHEN IT SHOULD, } AGAINST BAD CERTIFICATES OR DNS So yes, I need to create a test suite still, instead of relying upon ad-hoc testing against various servers. That said, while I wouldn't yet rely upon the tool for monitoring or assurance, it's useful for taking a look. Also: Go 1.8 is a very recent release; please do check version. This is not a frivolous requirement on my part: Go 1.8 introduced the hooks into the TLS certificate verification logic which I need to splice DANE logic in there. The code should "cleanly" fail to build with an obvious error message if an older toolchain is used. At present, smtpdane still relies upon a validating DNS resolver, instead of validating DNSSEC itself. For use as a monitoring component, I'd like to remove that dependency. smtpdane -help smtpdane -mx spodhuis.org Every MX host, every IP, connected to in parallel and success reported. Feedback welcome. There's a TODO of things I know still need to be done. Thanks, -Phil From ietf-dane at dukhovni.org Mon Feb 27 03:06:15 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 26 Feb 2017 21:06:15 -0500 Subject: Update on stats Message-ID: <20170227020615.GD92063@yyrkoon.imrryr.org> As of today I count 110505 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: 43813 domeneshop.no 35704 transip.nl 15495 udmedia.de 2022 bhosted.nl 1332 nederhost.net 896 ec-elements.com 409 core-networks.de 307 uvt.nl 282 bit.nl 275 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, and in particular .de and .nl. There are 2401 unique zones in which the underlying MX hosts are found, this counts each of the above providers 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 (2522) of distinct MX host server certificates that support the same ~110000 domains. Of the ~110000 domains, 565 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 64 (~4 are recent additions that will likely be resolved soon, the remaining ~60 are the for now stable population of broken domains). This month I'm posting the top 50 entries, these are domains that have been on that list for the longest time. Hall of Shame: castleturing.net goldenhairdafo.net dexalo.de nonoserver.info inu.nl dexalo.eu wm.net.nz dnsmadefree.com digitalwebpros.com apachedemo.de z0z0.me jeremyness.com oostergo.net pksvice.cz maximilian-greger.com thothnet.org ttygap.net copi.org wipedivision.cz bels.cz delphij.net rajmax.si baobrien.org poderdoalimento.com.br acsemb.org baobrien.guru rnrfunco.net dhautefeuille.eu pieterpottie.com sgt.com dinepont.fr sylvieandpieter.com rnrfunco.com hlfh.space sylviesfollies.com puz.de 12xu.info flatcap.org zencrypt.de warunek.net russon.org freeservices.net giesen.me amadigi.ovh kuzenkov.net kamikazekippetjes.nl duffau.net obninsk.biz myzt.nl daallexx.eu The number of domains with bad DNSSEC support is 434. The top 10 DNS providers (by broken domain count) are: 62 axc.nl - Slated to be resolved 37 infracom.nl - Slated to be resolved 18 loopia.se 18 active24.cz 16 domaincontrol.com - notified 14 jsr-it.nl 12 rdw.nl 12 cas-com.net 11 dootall.com - notified 10 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 99 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these 44 are in recent reports (February 2017): Hall of Fame: gmx.at mail.de asp4all.nl nic.br posteo.de ouderportaal.nl registro.br ruhr-uni-bochum.de overheid.nl gmx.ch tum.de xs4all.nl open.ch uni-erlangen.de domeneshop.no gmx.com unitymedia.de webcruitermail.no mail.com web.de debian.org trashmail.com enron.email freebsd.org xfinity.com octopuce.fr gentoo.org bayern.de comcast.net ietf.org bund.de dd24.net isc.org fau.de gmx.net netbsd.org gmx.de hr-manager.net samba.org jpberlin.de t-2.net torproject.org lrz.de xs4all.net A recent addition that is not listed above is "exim.org". It seems that "exim.org" mailing lists don't process enough email to land on Google transparency reports. Similarly, "openssl.org" used to be on this list, and still has working TLSA records, but it seems no longer generates enough email traffic to be on Google's reports. I don't have any way to measure how many domains enable DANE outbound but aren't using DNSSEC for their own domain or are not 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. So the stats I am reporting reflects only DANE adoption for inbound email. -- Viktor.