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.comwww.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/>
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
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
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.iohttps://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
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 :-)
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.
Are there any crpyto and DNS experts hanging out on this list who have some interest in building a large DNScrypt/DNScurve infrasructure with us?
We plan to reboot the internet into secure mode (www.bootstrap.is <http://www.bootstrap.is/>). contact me off list.
Hi,
I'm already running two DANE enabled MTAs and now tried to enable
another one.
I think I did all the same (the certificate is currently a self signed
one and the hostname does not match the certificate though).
But I read the Postfix documentation a few times now and I don't think
this is the issue.
Anyway testing sending from one of my already enabled Postfix systems to
the new one I only get "Anonymous TLS connection established" while the
DANE validator https://dane.sys4.de/smtp reports everything green for
the target.
Any ideas? (target is mail.tismail.net)
Thanks,
Wolfgang
