Re: [dane] Need better opportunistic terminology

[Viktor Dukhovni <[e-mail]>]

On Fri, Mar 07, 2014 at 04:35:06AM -0500, Michael Richardson wrote:

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

Yes.  This is quite common.  Servers generally don't know how and
whether clients perform TLS authentication.  The best they can hope
for is that clients find their certificates useful.  I should
however note that opportunistic DANE TLS sends SNI when the server
has TLSA records.  We don't yet know whether there are MTA
implementations which would fail to complete the TLS handshake when
they don't have a certificate with an exactly matching name.  The
draft requires servers to continue with a suitable default certificate
if no SNI match is found.

Since the draft precedes any significant deployment of SMTP servers
with TLSA records, one can hope that server operators will not
publish TLSA records if their server is "allergic" to "opportunistic"
DANE TLSA clients (really SNI hints that turn out to not match any
certificate configured on the server).  Thus far no such servers
have been observed, but the number of deployed clients and servers
is still quite small.

I am not aware of any MTAs that support server-side SNI, but this
could be mere ignorance.  If some do, those might be the ones that
get unhappy with unexpected SNI signals from clients.  Servers that
have completely ignored SNI to date (e.g. Postfix) will continue to
do so.

Any suggestions for a better name for this mode of operation?

-- 
	Viktor.