- dane-users - list.sys4.de

what's wrong?
by Andreas Schulze 14 Jul '15

14 Jul '15

Hello, messages to *(a)ewnederland.nl are deferred by postfix-3.0.x here. https://dane.sys4.de/smtp/ewnederland.nl say "No TLSA records." in contrast: # posttls-finger ewnederland.nl posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.remote.meulen.nl type=TLSA: Host not found, try again posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not found. Name service error for name=_25._tcp.remote.meulen.nl type=TLSA: Host not found, try again posttls-finger: Failed to establish session to ewnederland.nl via remote.meulen.nl: TLSA lookup error for remote.meulen.nl:25 as a workaround I configure "ewnederland.nl may" in smtp_tls_policy_map. are there better ways? Thanks Andreas -- Andreas Schulze Internetdienste | P252 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info(a)datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale

2 1

Please note: https://dane.sys4.de/common_mistakes#3
by Viktor Dukhovni 05 May '15

05 May '15

I'd like to draw everyone's attention to: https://dane.sys4.de/common_mistakes#3 When you are planning to replace certificates of SMTP servers with published TLSA records, you MUST *first* publish a transitional TLSA RRset: _25._tcp.mail.example.com. IN TLSA 3 1 1 <current-digest> _25._tcp.mail.example.com. IN TLSA 3 1 1 <next-digest> let that "burn in" for a few TTLs, while DNS caches time out the previous RRset containing only the current digest. Then and only then, deploy the certificate chain whose leaf (public key in the above example) digest is <next-digest>. Once that appears to work, you can remove the stale digest from DNS: _25._tcp.mail.example.com. IN TLSA 3 1 1 <next-now-current-digest> I am seeing an uptick in the number of sites that replace their certificates, but neglect to update their TLSA records. That's not a good plan. DO NOT DO THAT. If maintaining valid TLSA records is too difficult, don't publish them, you'll be forgiven. -- Viktor.

1 0

the upcoming Windows DNS server will support DANE records ...
by Carsten Strotmann (sys4) 16 Apr '15

16 Apr '15

Hi, the next Windows DNS Server will have support for DANE records, among other good stuff (RRL, Views, Application HA) https://technet.microsoft.com/en-us/library/dn765484.aspx -- Carsten

1 0

Dane testing and posttls-finger ???
by John Allen 11 Apr '15

11 Apr '15

When I try "posttls-finger dane.sys4.de" I get the following. I have emphasized a couple of areas in the following text that cause me some concern. posttls-finger: Connected to dane.sys4.de[194.126.158.134]:25 posttls-finger: < 220 dane.sys4.de ESMTP Postfix posttls-finger: > EHLO smtp.klam.ca posttls-finger: < 250-dane.sys4.de posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 10240000 posttls-finger: < 250-ETRN posttls-finger: < 250-STARTTLS posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: dane.sys4.de[194.126.158.134]:25: Matched subjectAltName: dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subjectAltName: sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25 CommonName dane.sys4.de posttls-finger:*certificate verification failed* for dane.sys4.de[194.126.158.134]:25: untrusted issuer /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority posttls-finger: dane.sys4.de[194.126.158.134]:25: subject_CN=dane.sys4.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=41:B5:70:D5:35:68:72:B2:64:4C:5E:DE:74:52:23:E1:3B:3A:03:07, pkey_fingerprint=E5:CD:96:DD:35:8C:91:30:75:5B:D0:66:47:1D:CD:83:39:9A:D5:CC posttls-finger:*Untrusted TLS connection *established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO smtp.klam.ca posttls-finger: < 250-dane.sys4.de posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 10240000 posttls-finger: < 250-ETRN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye Certificate verification fails and I wind up with an untrusted connection. Is this something I did or is there a real problem? John A

3 7

ANN: dane.sys4.de 1.0 released
by Patrick Ben Koetter 09 Apr '15

09 Apr '15

We've just released version 1.0 of https://dane.sys4.de. Among some bug fixes are many improvements to provide more meaningful output. We've also removed the table, listing DANE tested domains, from the homepage. Sites that already have been tested will now show up in a live search as soon as you start typing a domain name into the input field. Thank you all for your valuable input! p@rick (on behalf of the dane.sys4.de team) -- [*] 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

2 2

ANN: DANE testing (sink@dane.sys4.de)
by Patrick Ben Koetter 09 Apr '15

09 Apr '15

If you need a DNSSEC-enabled destination to test your DANE setup, send a message to sink(a)dane.sys4.de. It will accept your message and discard it. Check your log for a line "to dane.sys4.de". If it reads "Verified TLS connection" (Postfix) your DANE setup works properly. Here's a log example: Apr 8 19:52:31 mail postfix/smtp[28741]: Verified TLS connection established to dane.sys4.de[2001:1578:400:111::3:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) 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

3 3

DANE-enabled SMTP test destination?
by Kevin San Diego 08 Apr '15

08 Apr '15

Hi All, Does anyone know of an SMTP+DANE email reflector address where you can send test email to in order to validate proper SMTP client DANE behavior? No amount of creative Googling or the list archives seemed to surface an answer. Something akin to this, albeit for DANE: http://www.port25.com/support/authentication-center/email-verification/ Sincerely, Kevin San Diego

2 2

[ANN] pgpfinger - tool to retrieve PGP keys
by Markus Benning 27 Mar '15

27 Mar '15

Hello, while playing with DANE OPENPGPKEYS i wrote a tool i called pgpfinger. Its functionality may overlap with hash-slinger but i uploaded it in the hope it may be of use. It reads keys from sources: file, gpg, keyserver, dns And outputs in formats: armored, binary, generic, rfc Code and packages: https://github.com/benningm/pgpfinger Markus -- Markus Benning, https://markusbenning.de/

1 0

FREAK cipher-suite hygiene for Postfix
by Viktor Dukhovni 04 Mar '15

04 Mar '15

Now that the FREAK attack is widely disclosed, those of you who run SMTP servers that peer with clients that authenticate your server (be it via the traditional PKI or via DANE), might want to tighten-up your server cipher-suite settings just in-case: smtpd_tls_exclude_ciphers = EXPORT, LOW If nobody has yet elicited and factored any 512-bit RSA public keys from your server then your unpatched clients will be safe from the attack. (Not clear how you'd know this). If your server might have already signed one or more export RSA keys then its clients are potentially exposed to the attack for the lifetime of the server's long-term RSA keys. So, *after disabling* export grade algorithms, it may be prudent as appropriate to deploy new certificates. If you've published DANE TLSA records, follow the key rotation process described in: https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 Make sure to generate a new private/public key pair, rather than just re-use the existing key for a new certificate. Make sure to augment the TLSA record in DNS before deploying the new certificate, wait 2 TTLs or so, then deploy the new certificate and drop the obsolete instance of the TLSA record after. Note that while Postfix clients that do mandatory TLS (authenticated or not) do not enable EXPORT ciphers, the reason the FREAK bug is important is that such clients accept ephemeral RSA key transport with a 512-bit key anyway, while ostensibly negotiating a cipher-suite that does regular RSA key transport. This is a failure to exclude state transitions that should be disallowed in the SSL/TLS protocol state-machine. -- Viktor.

1 1

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