February 2015 - dane-users

education.lu
by Wolfgang Breyha 08 Apr '16

08 Apr '16

Hi! I'm testing the new exim 4.85 DANE support and it took only some days to get in trouble... One of our users tried to send mail to the domain education.lu. Their domain and MX hosts are DNSSEC enabled and have TLSA RRs. The DANE validator https://dane.sys4.de/smtp/education.lu says: "Unusable TLSA Records". Most likely because it is type 1 not allowed for DANE-SMTP? I've set hosts_try_dane = * in my SMTP transport. Exim refuses to talk to those hosts at all with "failure while setting up TLS session". Is this expected behavior in terms of DANE-SMTP? What's postfix doing in this case? Greetings, Wolfgang -- Wolfgang Breyha <wbreyha(a)gmx.net> | http://www.blafasel.at/ Vienna University Computer Center | Austria

8 29

Postfix DANE support for Certificate Usage = 0/1?
by Kevin San Diego 01 Mar '15

01 Mar '15

Hi All, I'm trying to get to speed on the DANE implementation in Postfix, it appears to support only DANE certificate usage 2 (Trust anchor assertion) and 3 (Domain-issued certificate). Is there a particular reason why the public CA-signed certificate types wouldn't be supported as these are more likely (as of today, at least) to be installed on business and commercial platforms? Extract from http://www.postfix.org/TLS_README.html#client_tls_dane: "The Postfix SMTP client supports only certificate usages "2" and "3" (with "1" treated as though it were "3"). See tls_dane_trust_anchor_digest_enable for usage "2" usability considerations. Support for certificate usage "1" is an experiment, it may be withdrawn in the future. Server operators SHOULD NOT publish TLSA records with usage "1"." Sincerely, Kevin San Diego

4 7

Fwd: SEMI-OT: Prohibiting RC4 Cipher Suites
by Andreas Fink 20 Feb '15

20 Feb '15

Side question: why is there a reply to: ietf-dane(a)sys4.de <mailto:ietf-dane@sys4.de> in the post. Hitting simple reply makes it fail. > > On 20 Feb 2015, at 20:15, Viktor Dukhovni <ietf-dane(a)dukhovni.org <mailto:ietf-dane@dukhovni.org>> wrote: > > On Fri, Feb 20, 2015 at 08:01:09PM +0100, Andreas Fink wrote: > > > Depends on what one one means by "fallback". >>> How about support (as a fallback) for older clients? How "safe" (no pun >>> intended) is it to disable as of today? >> >> Its simple: fallback = a MITM attacker can force fallback = youre pwned... >> Fall back in the sense of we tell the end user it was transported in a secure way but actually insecure encryption was used by the server and the MITM was able to decode it. If its acceptable to transfer in the clear in case TLS fails is something the mail operator might choose or not and it depends also on the specific link. For example I could say I know google mail supports TLS so only TLS would be permitted in my config but then if TLS steps down to RC4, i'm no longer protected from that assumption. > When RC4 is enabled > at a low preference MITM attackers cannot re-order the handshake > without invalidating the TLS "finished" message. Why this? a MITM attack implies the man in the middle terminates the TLS and thus he would in above example "mimic" the google mailserver's behaviour and simply would only offer RC4 inbound. Your sending mailserver would accept that as only option and use RC4 to deliver. So there's no "reordering" as its the only option provided. On the outbound connection, he simply would use a secure connection as usual to pass through the commands. > > I should be noted that, occasional bilateral security arrangements > aside, MTA to MTA SMTP is generally vulnerable to MiTM attacks > regardless of whether RC4 is enabled or not. > > With DANE, SMTP client MTAs can also authenticate servers for which > no prior security settings exist, and in *that* case we have a > fairly MiTM resistant protocol. > > In Postfix for peers that publish TLSA RRs, the "mandatory" TLS > protocol, cipher and exclusion lists apply. > > By all means, try: > > smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 > smtp_tls_mandatory_exclude_ciphers = RC4 > > If there are any domains that publish TLSA records for an SMTP > server that is capable only of legacy crypto, both they and I will > be surprised. > > -- > Viktor. > > -- Andreas Fink CEO DataCell ehf CEO Backbone ehf --------------------------------------------------------------- Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: andreas(a)fink.org www.datacell.com, www.backbone.is, www.finkconsulting.com www.fink.org --------------------------------------------------------------- Jabber/XMPP: andreas(a)fink.org ICQ: 8239353 Skype: andreasfink Support the reboot of the internet into secure mode: http://bootstrap.is <http://bootstrap.is/>

2 1

SEMI-OT: Prohibiting RC4 Cipher Suites
by Patrick Ben Koetter 20 Feb '15

20 Feb '15

A little off topic for DANE users, but somehow in scope. You might consider disabling RC4 in your servers cipher suite. IETF released an RFC requiring (...) that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246. -- Prohibiting RC4 Cipher Suites, https://tools.ietf.org/rfc/rfc7465.txt p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

5 8

SMIMEA TLS
by John Allen 17 Feb '15

17 Feb '15

Does anybody now if there are any developments in this standard and its implementation. Particular reference to email.

3 4

ICANN 52: DANE & Application Uses of DNSSEC
by Carsten Strotmann (sys4) 12 Feb '15

12 Feb '15

interesting presentations from ICANN 52: DANE & Application Uses of DNSSEC <http://singapore52.icann.org/en/schedule/wed-dnssec/presentation-dnssec-dan…> New DNSSEC Technologies: Paul Wouters, Red Hat <http://singapore52.icann.org/en/schedule/mon-tech/presentation-new-dnssec-t…>

1 0

Setting up Dane again from start
by Frank Fiene 12 Feb '15

12 Feb '15

Hi, just from start i did the following steps: 1.) Our DNS provider has secured the domain veka.com with DNSSEC: http://dnssec-debugger.verisignlabs.com/veka.com 2.) I’ve computed "openssl x509 -in mail.veka.com.crt -outform DER | openssl sha256“ the 256bit hash from the complete certificate chain which is used by Postfix as well. 04459a87d803ee5d2450114c09e8370dc51b27716431378cfa5560e153aed957 3.) Our DNS provider has added this to the domain and has signed it again (no idea why there is a blank!). _*._tcp.mail.veka.com. 3600 IN TLSA 3 0 1 04459A87D803EE5D2450114C09E8370DC51B27716431378CFA5560E1 53AED957 4.) I am still getting the error https://dane.sys4.de/smtp/veka.com In TLSA 3 0 1 should be correct, right? I ma using the whole certificate chain for the hash, the same certificate file i’ve configured within Postfix. _*._tcp.mail.veka.com. should be also working! So what might be the problem now? Kind regards! Frank -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene(a)veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster

7 15

Re: Setting up Dane again from start
by Frank Fiene 11 Feb '15

11 Feb '15

Am 11.02.2015 um 13:55 schrieb Frank Fiene <ffiene(a)veka.com>: Yeahhh. I should have followed this from the beginning! ;-) https://dane.sys4.de/smtp/fiene.io https://dane.sys4.de/smtp/veka.com It is working for me now. Many thanks to all! >> Am 11.02.2015 um 13:31 schrieb Michael Schwartzkopff <ms(a)sys4.de>: >> >> Am Mittwoch, 11. Februar 2015, 07:16:54 schrieb John: >>> On 2/11/2015 6:59 AM, Frank Fiene wrote: >>>> Damned, don’t any short documentation. :-( >>>> >>>> I’ve seen this on a website with a howto. >>>> >>>> >>>> I will test with all smtp Ports. >>>> This should work for pop3s and imaps, too, shouldn’t it? >>>> What is about pop3 and imap with TLS, the same? >>>> >>>> >>>> Frank >>>> >>>>> Am 11.02.2015 um 12:44 schrieb John <john(a)klam.ca>: >>>>> >>>>> That should have read - I am not 100% certain, but I don't think you can >>>>> use _*._tcp...... I think it has to be an actual port. In this case >>>>> _25._tcp. ma....... -- >>>>> John Allen >>>>> KLaM >>>>> ------------------------------------------ >>>>> How many of you believe in telekinesis? Raise my hand... >>>> >>>> Viele Grüße! >>>> i.A. Frank Fiene >>>> -- >>>> Frank Fiene >>>> IT-Security Manager VEKA Group >>>> >>>> Fon: +49 2526 29-6200 >>>> Fax: +49 2526 29-16-6200 >>>> mailto: ffiene(a)veka.com >>>> http://www.veka.com >>>> >>>> PGP-ID: 62112A51 >>>> PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 >>>> Threema: VZK5NDWW >>>> >>>> VEKA AG >>>> Dieselstr. 8 >>>> 48324 Sendenhorst >>>> Deutschland/Germany >>>> >>>> Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), >>>> Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner >>>> Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: >>>> Ulrich Weimer HRB 8282 AG Münster/District Court of Münster >>> >>> This is my setup for smtp and submission - >>> >>> _25._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca. >>> _587._tcp.smtp.klam.ca. IN CNAME tlsa301a._dane.klam.ca. >>> tlsa301a._dane.klam.ca. IN TLSA ( 3 0 1 5bf12300255d >>> >>> The credit for this goes to Viktor Dukhovni who advised me on how to set >>> it up, without his input I would still be flailing around. >> >> Yes. Carsten wrote a nice article in German. >> https://sys4.de/de/blog/2014/05/24/einen-tlsa-record-fuer-dane-mit-bind-9-p… >> >> It is really time to translate that doc. >> >> Mit freundlichen Grüßen, >> >> Michael Schwartzkopff >> >> -- >> [*] sys4 AG >> >> http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044 >> Franziskanerstraße 15, 81669 München >> >> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 >> Vorstand: Patrick Ben Koetter, Marc Schiffbauer >> Aufsichtsratsvorsitzender: Florian Kirstein > > Viele Grüße! > i.A. Frank Fiene > -- > Frank Fiene > IT-Security Manager VEKA Group > > Fon: +49 2526 29-6200 > Fax: +49 2526 29-16-6200 > mailto: ffiene(a)veka.com > http://www.veka.com > > PGP-ID: 62112A51 > PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 > Threema: VZK5NDWW > > VEKA AG > Dieselstr. 8 > 48324 Sendenhorst > Deutschland/Germany > > Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), > Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, > Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer > HRB 8282 AG Münster/District Court of Münster > Viele Grüße! i.A. Frank Fiene -- Frank Fiene IT-Security Manager VEKA Group Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene(a)veka.com http://www.veka.com PGP-ID: 62112A51 PGP-Fingerprint: 7E12 D61B 40F0 212D 5A55 765D 2A3B B29B 6211 2A51 Threema: VZK5NDWW VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO), Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler, Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer HRB 8282 AG Münster/District Court of Münster

1 0

Opportunistic DANE / TLS per host
by Michael Grimm 09 Feb '15

09 Feb '15

Hi -- Very recently I started to implement and investigate DNSSEC and DANE at a test server (separate FreeBSD jail with postfix). I am using OpenDNSSEC for key rollover management and KSKs and ZSKs with 2048-bits and algorithm 8. While learning (Open)DNSSEC I made a mistake (misuse of OpenDNSSEC functionality) and screwed my chain of trust, thus making my test server "unknown" to DNS. Well, I learned how to deal with that, but that experience made me think about a "fallback" setup for hosts that somehow managed to screw their chain of trust as well. http://www.postfix.org/TLS_README.html#client_tls_dane shows me an opt-in approach for opportunistic DANE (if I am not completely misunderstanding). What I want to implement is an opportunistic DANE approach with fallback to opportunistic TLS for "DANE broken" hosts, and implemented: postconf -n | grep ^smtp_: smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_generic_maps = pcre:/usr/local/etc/postfix/smtp_generic_maps smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 smtp_tls_note_starttls_offer = yes smtp_tls_protocols = !SSLv2 !SSLv3 plus "broken" hosts: transport_maps = pcre:/usr/local/etc/postfix/transport_maps /usr/local/etc/postfix/transport_maps /^example\.com/ opportunistic-tls master.cf: opportunistic-tls unix - - n - - smtp -o syslog_name=postfix/otls -o smtp_dns_support_level=enabled -o smtp_tls_security_level=may This is working on my test server, but before implementing that scheme on my productive server[1], I'd like to ask you experts out there: Do I miss something that might break my approach? Or, is there a more elegant way to implement a fallback oTLS? Thanks and regards, Michael [1] only a handful users, but outgoing mail should not fail, never :-)

3 4

IPv6 reverse zone
by John 05 Feb '15

05 Feb '15

Should I be signing my ip6.arpa. zones. Is ip6.arpa signed, and is so how do add my zone to the root. -- John Allen KLaM ------------------------------------------ If you are out to describe the truth, leave elegance to the tailor.

4 3