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 21:56:13
On Tue, Aug 05, 2014 at 07:26:10PM -0700, Dave Crocker wrote:

On 8/5/2014 6:27 PM, Viktor Dukhovni wrote:
It is when authentication is then used *only* with peers that
publish TLSA RRs and not with peers that don't. 


My point was/is that reliance on DNSSec means that there is an
INDEPENDENT authentication hierarchy.

Taking a look at the entire 'system' that DANE is part of, the
authentication is NOT only between peers.

Use DANE without DNSSec, and calling it opportunistic probably makes
sense.  Using it with DNSSec and it doesn't.

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

If opportunistic security is mutually exclusive with protection
against active attacks, it is a step sideways not forward.  I am
proposing to make encryption more ubiquitous *without* lowering
the achievable security.  I believe I have strong support for this
in this forum (both saag and ietf general).

For SMTP, the resulting protocol is "opportunistic DANE TLS", which
is an example of an "opportunistic security" design.

You're bringing baggage to this discussion in the form of assumptions
about what opportunistic security means.  The draft proposes a more
ambitious definition.

-- 
        Viktor.

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