withdrawn
The TLSA-Records are also dnssec - signed; so no need for a https signaling..
Page is left here as a learning example.
This insight was confirmed during a technical discussion with Viktor Dukhovni (author of [RFC7672]), who clarified that DNSSEC validation cannot be "silently stripped" when a resolver validates signatures correctly.
Thank you Viktor. :-)
If you plan to use DANE be sure to follow < the best practices and read the postfix documentation; like is this German Version ( preferred:-) ) -> thoughts in german
What's the problem?
While DNSSEC is a valid, strong defence against MITM-Attacks and verifying the correct receiver, this protocol has an often overlooked weakness:When the attacker is able to see traffic on port 25 (smtp),
it is very likely that he also can see the traffic on port 53 (DNS)
- and by sending faster faked responses he is able to convice the real sender to not use and trust dnssec in the connection. It is even possible to send a new destination, which would be accepted by the sender.
Here I present a solution to force DNSSEC when possible. One may not rely on DNS UDP packets when starting a new connection.
Overview
This site presents a proposal for extending MTA-STS to include DNSSEC validation hints, allowing sending MTAs to detect tampering on the DNS resolution path. The mechanism is fully backward-compatible and does not require changes to SMTP or DNS protocols.
Draft Specification
The Internet-Draft draft-frickl-mta-sts-dnssec-policy-02 is available:
Background
While DNSSEC provides cryptographic assurance of DNS records, many clients do not enforce its presence. MTA-STS operates over HTTPS but ignores DNSSEC. This draft proposes combining both approaches to signal that DNSSEC validation is required for secure delivery.
Contact
Feedback is welcome. Please contact: gn@frickl.de
PGP: public key
Fingerprint: 1C92 45B5 D682 EF89 6AE5 C7C4 4FD3 105C D91D B248