On 23 Aug 2015, at 20:50, Peter Koch wrote: > If we'd only be worried about a passive attacker, we'd not > address the spoofed MX RR, but we'd want the SMTP connection > encrypted. In that case (passive only), opportunistic (pre DANE) > STARTTLS would be sufficient. > > If we'd worry enough about active attacks, we'd want the endpoint > identity verified (thus DANE[1]) as well as its capabilities > (thus DANE[2]), and at the same time we'd probably prefer (or > even demand) signed/validated MX RRs. > > Apparently there are multiple potential attackers of different background, > motivation, and means. If your enemy is the helpful corporate > firewall that intercepts SMTP to 'optimize away' STARTTLS, maybe > its next version will 'enhance' MX responses?
Agree. What I think I see in the draft is that "DANE and SMTP" is either "on" or "off", and I want more shades of gray. 1. Unsigned MX, Unsigned A/AAAA, not using TLS at all 2. Unsigned MX, Unsigned A/AAAA, TLS used with self-signed cert 3. Unsigned MX, Unsigned A/AAAA, TLS used with cert signed by CA (i.e. trusted cert) 4. Unsigned MX, Signed A/AAAA, TLS used with cert signed by CA (i.e. trusted cert) 5. Unsigned MX, Signed A/AAAA, TLS used with cert validated with signed TLSA (i.e. trusted cert) 6. Signed MX, Signed A/AAAA, TLS used with cert validated with signed TLSA I think 4 and 5 are equivalent, both better than 3 (which is better than 1, 2 and 3). And of course there are more permutations, specifically with signed MX, but the for me interesting alternatives are the ones above, where MX is unsigned. Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
