I'm afraid the below is a strawman hypothetical. Please stop. DNSSEC lookups either return the truth or explicitly *FAIL*, they don't just return "neutral" results.
As, for example, explained in RFC7672, when TLSA lookups fail the mail delivery is deferred, and may ultimately bounce if the condition persists beyond the message queue lifetime. The same is repeated in RFC7673: https://tools.ietf.org/html/rfc7673#section-3.4 o If the TLSA response is "bogus" or "indeterminate" (or the lookup fails for reasons other than no records), then the client MUST NOT connect to the target server (the client can still use other SRV targets). Indeed in RFC6698 (base DANE specification) the state machine in Appendix B.2 is: https://tools.ietf.org/html/rfc6698#appendix-B.2 (TLSArecords, ValState) = DNSSECValidatedLookup( domainname=_[port]._[transport].[name], RRtype=TLSA) // check for states that would change processing if (ValState == BOGUS) { Finish(ABORT_TLS) } if ((ValState == INDETERMINATE) or (ValState == INSECURE)) { Finish(NO_TLSA) } // if here, ValState must be SECURE ... > On Sep 14, 2018, at 11:18 AM, Richard Barnes <r...@ipv.sx> wrote: > > One other bit of context here: DANE itself doesn't prevent these "downgrade" > attacks in its native form, to say nothing of TLS. This is simply false. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
