Viktor Dukhovni <[email protected]> wrote: > So you might ask what was the word "opportunistic" doing in our > avant-garde use of the term "opportunistic DANE TLS"? The answer is > that as with (pre-DANE) opportunistic TLS, the client is willing to > send in the clear to any server for which no "secure" TLSA records are > available.
> Thus, until the happy future when a significant fraction of domains are
> DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated
> "secure" TLSA records, in practice the protocol is essentially the same
> as with (pre-DANE) opportunistic TLS. The client employs the best
> security level available (including cleartext).
And, in particular, I think that "opportunistics TLS" interoperates with
"opportunistics DANE TLS". The two sides don't have to have to known each
other's policies.
> So Phillip is quite right that DANE gets us stronger semantics, but I
> would argue, that because the actual security posture is *conditional*
> on published receiving system capabilities, from the perspective of the
> sending system, this is just a "hardened" version of opportunistic TLS
> where, for just some destinations not known to the sender in advance,
> MITM attacks cannot trivially downgrade senders to plaintext or
> compromise transport integrity or confidentiality.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting for hire =-
pgpIMVLD_4hwy.pgp
Description: PGP signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
