ietf
[Top] [All Lists]

Re: [saag] Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

2014-08-05 22:14:49
On Tuesday, August 05, 2014 19:58:51 Dave Crocker wrote:
On 8/5/2014 7:55 PM, Viktor Dukhovni wrote:
We'll have to disagree on this.  From the perspective of an MTA
delivering mail to all possible domains, its security policy is
opportunistic, doing the best it can with each destination.  When
DANE support is enabled, it becomes possible to authenticate some
peers, this is still opportunistic security, with the bar set to
the right level for each peer, and mail delivery in cleartext should
a previously DANE-enabled domain withdraw its TLSA RRs, ...

I've read the above several times but do not really understand what it
means.

Also the issue is not whether we agree  but what the technical details
are that qualify this as "opportunistic" rather than authenticated
encryption that happens to use DNSSec as a form of CA.

For a term to be useful, there must be a clear and consistent way of
applying it.

The exchange we are having right now makes the meaning -- and therefore
utility -- of opportunisitc (foo) -- questionable.  It is simply not
useful to have such a basic assessment reduce to "we'll have to disagree"...

It seems to me that all it means is that the MTA is taking the opportunity to 
make the most secure connection it can on a peer basis.  Sometime that's going 
to be a full DANE negotiated session protected by DNSSEC.  Other times it's 
not.  I think the major point of opportunistic isn't how good the resulting 
security is, but the idea of taking advantage of the best option available on 
a per peer basis rather than treating it as all or nothing.

Scott K

<Prev in Thread] Current Thread [Next in Thread>