From 0e3d385d714112ea98fd30c600cf39c4566024f9 Mon Sep 17 00:00:00 2001 From: Dennis Baaten Date: Mon, 2 Dec 2019 22:36:24 +0100 Subject: [PATCH] Update DANE-for-SMTP-how-to.md --- DANE-for-SMTP-how-to.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DANE-for-SMTP-how-to.md b/DANE-for-SMTP-how-to.md index ae3dff0..9819c6f 100644 --- a/DANE-for-SMTP-how-to.md +++ b/DANE-for-SMTP-how-to.md @@ -192,7 +192,7 @@ This section describes several pionts for attention when implementing DANE for S * DANE relies on the security that is provided by DNSSEC. Make your primary domain and MX domain support DNSSEC before implementing DANE. It is important that DNSSEC is implemented properly. A lot of DANE breakage stems from receiving/recipient domains with broken DNSSEC implementations. * Purchasing of expensive certificates for mail servers has no to little added value for the confidentiality since mail servers don't validate certificates by default. Depending on the context there can be other advantages which makes organizations decide to use specific certificates. * It is possible to use self-signed certificates. - * [Section 3.2 of RFC 7672](https://tools.ietf.org/html/rfc7672#section-3.2) states that SMTP clients must **not** perform certificate name checks when using an end-entity certificate (usage type 3), but must perform certificate name checks when using an intermediate or root certificate (usage type 2). + * [Section 3.2 of RFC 7672](https://tools.ietf.org/html/rfc7672#section-3.2) states that SMTP clients **must not** perform certificate name checks when using an end-entity certificate (usage type 3). However, it also states that SMTP clients **must** perform certificate name checks when using an intermediate or root certificate (usage type 2). The latter is necessary to prevent attackers from abusing a random intermediate or root certificate to falsely validate their evil mail servers. * [Section 3.1 of RFC 7672](https://tools.ietf.org/html/rfc7672#section-3.1) states that the expiration date of the end-entity certificate MUST be ignored. * It is recommended to use a certificates public key for generating a TLSA signature (selector type "1") instead of the full certificate (selector type "0"), because this enables the reuse of key materials. Alghough it is wise te refresh your key material once in a while, note that the use of Forward Secrecy decreases the need to use a new key-pair on every occasion. * An issuer certificate (usage type "2") validates only when the full certificate chain is offered by the receiving mail server.