Zitat von Patrik Fältström <[email protected]>:

On 23 Aug 2015, at 19:47, Paul Wouters wrote:

On Sun, 23 Aug 2015, Patrik Fältström wrote:

Also, in my example the RRSet the MX is in is _unsigned_:

example.com. IN MX 0 mail.example.net.

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 ....

I.e. if only looking at mail.example.com. and _426._tcp.mail.example.com. that is a 100% properly setup DANE "thing".

I think you are arguing that it should deliver TLS only after validation
of the TLSA record for mail.example.net. That validation is a false
sense of security though.

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.

To my knowledge with Postfix this should lead to a "normal" TLS connection with no DANE at all for "dane" level:

"The Postfix SMTP client will not look for TLSA records associated with MX hosts whose "A" or "AAAA" records lie in an "insecure" DNS zone."

With dane-only the connection might fail.

Regards

Andreas


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to