Security Model » History » Revision 2
Revision 1 (Marc Dequènes, 2020-04-06 13:58) → Revision 2/6 (Marc Dequènes, 2020-04-06 14:13)
h1. Security Model DANE h2. Status in DuckCorp Introduction h3. DNS We would prefer not "DANE":https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities is a security protocol used to have to trust reinforce TLS certificate validation by publishing certain information in the DNS. It requires your DNS hierarchy, but, it is convenient for most users and alternative systems at the moment did not solve the problem in a satisfactory manner. Our zones are to be secured using DNSSEC. Tenants' zones will be signed when handling the KSK rollover with the parent zone is smooth enough (and fully automated, WIP). "DNSSEC":https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions. h3. TLS Certificates h2. Status in DuckCorp We consider it is better not to trust top CAs and their "broken security model":https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise. Instead DANE-EE allows validation of the leaf certificate, bypassing the usual CA validation. It still requires trusting the DNS hierarchy, but there are less players involved it has proved more reliable, so this is a real improvement. Unfortunately DANE adoption is quite low. Initially we only used our own CA and published TLSA records for all services. Because it's quite inconvenient to setup a custom CA for non-technical users and because it makes our life difficult to communicate and exchange with external entities through our infrastructure, we decided to trust Let's Encrypt to generate certificates. The root of the problem is not solved but at least the validation process is sound and open. It is also automated, using Free Softwares, so we can handle certificate management by ourselves. We keep using our CA for internal services but public-facing ones now use Let's encrypt. Since we now use Let's Encrypt, TLSA publication has been reworked to play nice together. It is fully automated (compared to renewal with our CA) but currently not deployed for all services yet. h2. DNSSEC See [[DNS#DNSSEC]]. h2. DANE h3. Introduction "DANE":https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities is a security protocol used to reinforce TLS certificate validation by publishing certain information in the DNS. It requires your DNS zones to be secured using "DNSSEC":https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions. h3. Checking DANE The "danetls":https://github.com/shuque/danetls tool is not packaged but there is a web service called "danecheck":https://www.huque.com/bin/danecheck by the same author. h3. h2. DANE adoption These are just notes to check on DANE adoption in various client software. * HTTPS: "plugins for majors browsers were developed and abandoned":https://www.dnssec-validator.cz/ because necessary API support in the browsers vanished and there is no replacement * SMTP: seems to have gained traction, suggested by the various checkers, Postfix supports it and we support it (see [[Mail]]) * IMAP/POP3: "Thunderbird integration was refused":https://bugzilla.mozilla.org/show_bug.cgi?id=1479423 because it needs to be integrated in Firefox core first, but the "Firefox integration":https://bugzilla.mozilla.org/show_bug.cgi?id=672600 does not seem to go anywhere * IRC: "Weechat integration":https://github.com/weechat/weechat/pull/121 is not making much progress despite a patch being available * XMPP-c2s: ??? * XMPP-s2s: Prodosy has an "experimental module":https://modules.prosody.im/mod_s2s_auth_dane.html but it is unmaintained and supposed to crash sometimes (according to the known issues)