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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]