Re: [saag]: Review of: Opportunistic Security -03 preview for comment

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

 



On Fri, 15 Aug 2014, Viktor Dukhovni wrote:

On Fri, Aug 15, 2014 at 03:01:59PM -0400, Paul Wouters wrote:

Background Encryption ?
Preemptive Encryption ?
Preventive Encryption ?
Preventative Encryption ?
Countermeassure Encryption ?
Remedial Encryption ?

This boat has sailed:

   TLS -> TLE: Transport Layer Encryption?
   IPsec -> IPenc: IP encryption?
   SSH -> ESH: Encrypted SHell?
   HTTPS -> HTTPE: HTTP over TLE?
   ...

All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus
there have a legitimate reason to call it security and not just
encryption.

Let's talk about the substance of the draft.

This draft proposes encryption in the possible absence of
authentication. While I can call it privacy or encryption,
I have a very hard time calling it security. On top of that,
we all know we would have called ie opportunistic encryption
if that term had not been picked already. We know the term is
a workaround. Some just feel it is a bad workaround. For its
implied (misleading) meaning and for its terrible acronym of "OS".

RFC 4949 states:

$ security
      1a. (I) A system condition that results from the establishment and
      maintenance of measures to protect the system.

      1b. (I) A system condition in which system resources are free from
      unauthorized access and from unauthorized or accidental change,
      destruction, or loss. (Compare: safety.)

      2. (I) Measures taken to protect a system.

      Tutorial: Parker [Park] suggests that providing a condition of
      system security may involve the following six basic functions,
      which overlap to some extent:
      -  "Deterrence": Reducing an intelligent threat by discouraging
         action, such as by fear or doubt. (See: attack, threat action.)
      -  "Avoidance": Reducing a risk by either reducing the value of
         the potential loss or reducing the probability that the loss
         will occur. (See: risk analysis. Compare: "risk avoidance"
         under "risk".)
      -  "Prevention": Impeding or thwarting a potential security
         violation by deploying a countermeasure.
      -  "Detection": Determining that a security violation is
         impending, is in progress, or has recently occurred, and thus
         make it possible to reduce the potential loss. (See: intrusion
         detection.)
      -  "Recovery": Restoring a normal state of system operation by
         compensating for a security violation, possibly by eliminating
         or repairing its effects. (See: contingency plan, main entry
         for "recovery".)
      -  "Correction": Changing a security architecture to eliminate or
         reduce the risk of reoccurrence of a security violation or
         threat consequence, such as by eliminating a vulnerability.


The draft covers none of these listed items - it should not be called
"XXX security"

Paul





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