Subject: [saag] suggested text for opportunistic definition

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 01:23:01 +0100

Hi,

I tried to see what the Steve's definition would look like if
my comments were applied to it and came up with this. I tried
to keep the numbering as close to the draft as I could to make
it easier to compare.

S.

Opportunistic Security (OS) is a descriptive term
for how security is handled in protocols that
exhibit the following characteristics:

   0.  OS involves establishing and using shared
secrets to provide confidentiality for
communications between endpoints, even if there is
no guarantee of the identities of the endpoints (so
that one of them could be a Man-in-the-Middle).

   1.  OS is generally invisible to users, (no "lock
icons") and, more broadly, to applications that
initiate sessions.  Lack of visibility is important,
so that users or application administrators do not
become confused by the variability in the set of
security services they are being afforded.  This
allows applications to benefit from opportunistic
security without user or administrator intervention.

   2.  Opportunistic security is not a substitute
for endpoint authentication, when that security
service can be provided. Authentication of endpoints
makes various attacks much harder and continues to
have significant value. In various protocols OS can
be seen as establishing a "floor" for security where
the "ceiling" is a higher security state, perhaps
with all endpoints authenticated. The floor and
ceiling states will vary by protocol.

   3.  OS security is strongly recommended to use
Perfect Forward Secrecy for key agreement.

   5.  Detection of man-in-the-middle (MiTM) attacks
is a desired, thought not mandatory, feature.  If
crypto-based authentication cannot be achieved, it
may still be possible to detect a MiTM.  MiTM
detection is considered a lower priority than
(crypto-based) authentication.

   6.  In some contexts, delays in
session/connection establishment might discourage
use of OS.  In such contexts, authentication and
MiTM detection might take place only after an
encrypted session is established.  This could imply
that application data could be transmitted prior to
authentication or steps that would result in
detection of a MiTM.

   7.  Because OS entails a relatively new key
management paradigm, it requires new capabilities by
peers which may take some time to be deployed.
Thus, until OS is universally adopted for
deployments of a protocol, attempts to establish
confidentiality may fail, and the session might
fallback to plaintext communication.  Since an
attempt to use OS is not communicated to users or
applications, falling back to the status quo, i.e.,
plaintext communication, can be a reasonable
strategy.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Apr 2014 04:36:59 +0000

> to keep the numbering as close to the draft as I could to make

The comments are improvements in the list of "features" of
opportunistic security, but there is still a hole in the shape of
a missing high level definition of what the term actually means,
or more precisely what are the goals and motivations rather than
features of opportunistic security.  Here's a partial list:

    - A suitably phrased "universal interoperability" goal.  In
      other words, opportunistic security's primary goal is to be
      able to connect to any reasonably configured peer.  If a
      non-trivial fraction of peers are only capable of cleartext[1],
      then it is OK to fall back to cleartext when encryption is not
      possible with a given peer.  If authentication is only possible
      for some peers, then it is OK to authenticate only those peers
      and not the rest.

      This interoperability must be possible without bilateral
      coordination, that is applications employing opportunistic
      security need to be deployable at Internet scale, with each
      peer independently configuring their end to meet their needs
      (within reason and the bounds of the application protocol)
      and opportunistic security not getting in the way of the
      peers communicating if neither end is misconfigured.

    - Subject to the "universal interoperability" goal, which sets
      the floor low enough to interoperate on a large scale
      opportunistic security strives to maximize security (reaches
      for a higher ceiling), given the capabilities of the peer
      (or peers).  For many opportunistic protocols the maximal
      ceiling may be just unauthenticated encryption.  For some,
      via DANE, TOFU, ... the ceiling will be higher with some
      peers, and opportunistic security may at times (in partial
      conflict with the prime directive above) refuse to
      connect with peers where higher security is expected.  The
      conditions under which connections fail should generally
      be limited to operational errors at one or the other peer,
      so that well-maintained systems do not encounter problems
      in normal use of opportunistic encryption.

      Of course for systems with sufficiently recent software and
      configurations that don't explicitly disable security features,
      at least unauthenticated encryption MUST be possible.  An
      opportunistic security protocol MUST interoperably reach at
      least this level of security between typical peer systems.
      Over time only legacy systems or a minority of systems where
      encryption is not an option should be communicating in cleartext.

    - No misrepresentation of the security level achieved,
      unauthenticated connections or authentication that is vulnerable
      to MiTM attacks is not represented as strong security.  Where strong
      security is required, opportunistic security is not a substitute,
      though the underlying mechanisms may in some cases be very similar,
      e.g. both use TLS.

    - Almost all other aspects of opportunistic security are
      illustrative, and aspirational rather than essential to the
      definition.  Thus for example PFS, or UI considerations may
      in some cases typically apply to opportunistic security
      protocols and may be generally desirable, but are still
      non-essential features.  A list of such features (such as
      the updated feature list) is a reasonable set of considerations
      for designers opportunistic protocols, but is not really IMHO
      part of the definition of the term.

So bottom-line I'd like to see a draft with a good definition, and
only then a list of associated design considerations, that might
even predominantly focus on the counter-PM use-case (if that's
explicitly stated).  The draft should not however attempt to define
OS as only a counter-PM technology.

Rather OS is a more pragmatic approach to baking security into
Internet protocols, where deployable security that works for most
is valued more highly than strongest available security that works
only for some.

-- 
	Viktor.

[1] I use cleartext to refer to content that is transmitted
unencrypted, as opposed to plaintext which is the not yet encrypted
or already decrypted form of content that is sent encrypted).

---

From: Michael Richardson <[email-masked]>
Date: Sun, 27 Apr 2014 07:02:14 -0400

Stephen Farrell <[email-masked]> wrote:
    >    1.  OS is generally invisible to users, (no "lock icons") and, more
    > broadly, to applications that initiate sessions.  Lack of visibility is
    > important, so that users or application administrators do not become
    > confused by the variability in the set of security services they are
    > being afforded.  This allows applications to benefit from opportunistic

So you write "invisible to users", which I agree with strongly.
Then you write "application administrators", and I'm not sure who those
people are.  Is it a distinct group from "system administrators"?

What I am concerned about is that some might take this to mean that
an administrator viewable audit log is undesireable; such a log is necessary
in order for the admin to figure out:
  1) why wasn't OS enabled for connection FOO?
  2) was there a MITM on that connection last week?
  ( 3) given a Heartbleed-type bug, was I vulnerable? )

... in my mind, received: by lines for SMTP is a good example of how to do
this well.

    >    7.  Because OS entails a relatively new key management paradigm, it
    > requires new capabilities by peers which may take some time to be
    > deployed.  Thus, until OS is universally adopted for deployments of a
    > protocol, attempts to establish confidentiality may fail, and the
    > session might fallback to plaintext communication.  Since an attempt to
    > use OS is not communicated to users or applications, falling back to
    > the status quo, i.e., plaintext communication, can be a reasonable
    > strategy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 13:37:40 +0100

Hiya,

> features of opportunistic security.  Here's a partial list:

I pretty much agree with your list, but its not text that could
be cut'n'pasted into a draft.

I did try to capture the basic definition in my point#0:

"   0.  OS involves establishing and using shared
secrets to provide confidentiality for
communications between endpoints, even if there is
no guarantee of the identities of the endpoints (so
that one of them could be a Man-in-the-Middle)."

Would it be possible/useful if you were to modify that
to capture what you think needs capturing? (In as few
words as possible:-)

Or even maybe try suggest an alternative for the whole
thing if you've energy.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 13:43:23 +0100

Hiya,

On 27/04/14 12:02, Michael Richardson wrote:
>> 1.  OS is generally invisible to users, (no "lock icons") and,
>> more broadly, to applications that initiate sessions.  Lack of
>> visibility is important, so that users or application
>> administrators do not become confused by the variability in the
>> set of security services they are being afforded.  This allows
>> applications to benefit from opportunistic security without user
>> or administrator intervention.
> 
> Then you write "application administrators", and I'm not sure who
> those people are.  Is it a distinct group from "system
> administrators"?

Yep, I didn't write that very well I agree.

> 
> What I am concerned about is that some might take this to mean
> that an administrator viewable audit log is undesireable; such a
> log is necessary in order for the admin to figure out: 1) why
> wasn't OS enabled for connection FOO? 2) was there a MITM on that
> connection last week? ( 3) given a Heartbleed-type bug, was I
> vulnerable? )
> 
> ... in my mind, received: by lines for SMTP is a good example of
> how to do this well.

Agreed.

The reason I (badly) tried to add that was that the point has
been made that if an implementation does OS and makes turning
that on a configuration option for an admin then that admin
may well think "security, great, I'm done with OS."

Viktor's text about not misrepresenting the security level
seems better than what I wrote though.

S.

> 
>> 7.  Because OS entails a relatively new key management paradigm,
>> it requires new capabilities by peers which may take some time to
>> be deployed.  Thus, until OS is universally adopted for
>> deployments of a protocol, attempts to establish confidentiality
>> may fail, and the session might fallback to plaintext
>> communication.  Since an attempt to use OS is not communicated to
>> users or applications, falling back to the status quo, i.e.,
>> plaintext communication, can be a reasonable strategy.
> 
> -- Michael Richardson <[email-masked]>, Sandelman Software
> Works -= IPv6 IoT consulting =-
> 
> 
>