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-07 10:04:35
On Thu, Aug 07, 2014 at 10:43:14AM -0400, Stephen Kent wrote:

Well, the term "opportunistic security" surely feels more encompassing
compared to "opportunistic encryption". If we are only talking about
encryption, don't call it security.

Not everyone is in agreement about the scope of OS, as these continuing
discussions illustrate :-).

Indeed:

  - Rene Struik is concerned that opportunistic security might
    lead to a reduction in protection against active attacks,

  - You seem to want to ensure that opportunistic security should
    avoid defending against active attacks,

  - And I am suggesting adaptive behaviour that protects against
    active attacks when the peer is known to support authentication
    (via whichever key management technique from DANE, TOFU, ... is
    applicable to the situation at hand).

I can address Rene's concern, by adding some text to explain that
OS coexists with existing mandatory security policies, and is
intended to handle the cases in which mandatory policy does not
apply.  Protocol designs should however be aware that trying to
apply mandatory policy too broadly can have negative consequences,
and that OS may well be a better fit in many situations.

As for a desire to cap the definition of OS at unauthenticated
encryption, I'm afraid I've seen no compelling rationale for that.
It runs counter to Rene's concerns, and counter to the opportunistic
use of DANE authentication in Postfix, and would fail to encourage
other designers of adaptive protocols to consider authenticated
modes of operation.

Note, the draft DOES NOT require that OS protocols be able to
support authentication, it encourages protocol designers to consider
the option.  It is even likely that OS designs for near-term wide
deployment will not be able to offer authentication, since DANE is
not yet ready for prime-time (DNSSEC adoption barrier).  And yet
I see no reason to artificially cap the ceiling or preclude the use
of DANE for opportunistic authentication before we even get the 
chance to try it.

-- 
        Viktor.

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