search

internetstandards / toolbox-wiki

Internet.nl toolbox - how-to's for modern mail security standards (DMARC, DKIM, SPF and DANE)
147 stars 20 forks source link

Comments upon reading DANE document #4

Open abrotman opened 4 years ago

abrotman commented 4 years ago

1) Search for "is is" and "not not", a couple of typos. 2) For the section titled "Why use DANE for SMTP?", it seems to be backward. The section first notes the dangers, and it should perhaps instead list the advantages first. Might need to rework that section. 3) There are two illustrations titled "Mail delivery: TLS with MITM using evil certificate", not sure if that was intentional, seems like the second is about stripping the STARTTLS. Additionally, for that section (and elsewhere), might want to note that some devices intentionally remove STARTTLS from the response. I believe a Cisco PIX was a device that would regularly do this (for "security" reasons). 4) You may want to include an example where the DNS response was altered in order to send the sender to a different destination, something DNSSEC would help protect against. 5) I'd have to double check, but I believe that changing only the expiration date of a certificate does not generate a new hash. As such, if you're merely updating expired certs, you may not need to update the TLSA records. (a deployment consideration) 6) You may want to mention TLSRPT as a way to get some feedback about DANE deployments.

dennisbaaten commented 4 years ago

  1. Done.

  2. The idea was to reason from the risk of not using DANE. That's why I start with some shortcomings when DANE is not used, and then explain how DANE addresses these shortcomings. By following this particular order, I figured it would be easier to understand the advantages. I added a small intro to this section in an attempt to avoid possible confusions.

  3. Copy-paste mistake in the title. Corrected it.

dennisbaaten commented 4 years ago

  1. I added an extra paragraph explaining why DNSSEC is important.

  2. The TLSA records only need to change if the certificate (public key) changes. If they key pair remains the same, there is no need to upgrade the TLSA records. Although I personally advise against the use of key pairs for a long time (let's say: more than a year), the risk of reusing key pairs can be reduced by using forward secrecy.

  3. Will look into TLS-RPT.