Git/email-toolbox-wiki
1
0
Fork 0
mirror of https://github.com/internetstandards/toolbox-wiki.git synced 2024-11-24 03:51:36 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update DANE-for-SMTP-how-to.md

Browse Source
This commit is contained in:
Dennis Baaten 2019-12-02 22:36:24 +01:00 committed by GitHub
parent 2bbe140d64
commit 0e3d385d71
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
DANE-for-SMTP-how-to.md
View File

@ -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. * 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. * 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. * 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. * [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. * 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. * An issuer certificate (usage type "2") validates only when the full certificate chain is offered by the receiving mail server.