On Sun, 23 Aug 2015, Patrik Fältström wrote:
2. Delivery of the mail over TLS to mail.example.net.
so example.com is unsigned? and mail.example.net is signed, and the TLSA
record in example.net is signed.
Correct.
In that case, I believe TLS will be used but the TLSA cannot be
verified, so while delivery happens over TLS, there is no way to
verify the identity of the receiver because the MX record could have
been spoofed.
Excuse me for being slow here. What do you mean by "the TLSA cannot be
verified"?
To be more precise:
Unsigned RRSET contain:
example.net. IN MX 0 mail.example.com.
Signed (and properly validated) RRSETs that contains these two records and a
few more:
mail.example.com. IN A 192.168.1.1
_426._tcp.mail.example.om. IN TLSA ....
so anyone can spoof:
example.net. IN MX 0 mail.example.com.
pretending "mail.example.com." does not give you more security. What
would you do if you saw:
example.net. IN MX 0 evil.nohats.ca
with proper TLSA records for evil.nohats.ca?
I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. that is a 100%
properly setup DANE "thing".
But nothing in that statement securely tells you anything about example.net.
I don't think mail delivery will be halted. since the example.com domain
is unsigned, anonymous TLS will be used when available, and no
verification will take place.
I'm not sure what you are proposing to change?
I am not sure I am proposing a change. :-)
What seems to have happened in the tests that Jan did was that IF the MX was
not signed, BUT the TLSA was signed and validated correctly, THEN postfix did
_NOT_ deliver the email. At all.
I think that behaviour is wrong, and am unsure whether it is a bug in postfix
or whether it is a bug in the spec.
That would be a bug in postfix? The spec states:
All
"insecure" RRSets MUST be handled identically: in either case
unvalidated data for the query domain is all that is and can be
available, and authentication using the data is impossible.
It does not state to not deliver email, it just states there is no
authentication possible, so deliver without dane authentication.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
