On Fri, Sep 14, 2018 at 8:33 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > In theory perhaps, but as a practical matter, no browser client, at least, can do DNSSEC hard fail, because the rate of organic DNSSEC interference is too high. Indeed, this is the primary reason why DANE over TLS is interesting. -Ekr > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
