You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Search for "is is" and "not not", a couple of typos.
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.
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).
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.
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)
You may want to mention TLSRPT as a way to get some feedback about DANE deployments.
The text was updated successfully, but these errors were encountered:
abrotman
changed the title
Comments upon reading
Comments upon reading DANE document
Jul 30, 2019
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.
I added an extra paragraph explaining why DNSSEC is important.
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.
The text was updated successfully, but these errors were encountered: