Subject: [saag] OS features/requirements analysis

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2014 15:19:55 -0400

I reported that a breakout session at the STRINT workshop identified 
several features that should be part of opportunistic security. It has 
been suggested that at least one of these, PFS, ought not be mandatory. 
I suggest we explicitly review all of the proposed features for OS and 
decide which are mandatory, which are optional, and which have no place 
in a definition for OS.

Here is the list I recall from the workshop, with a rationale for each 
feature:

1.OS is invisible to users, and, more broadly, to applications that

initiate sessions.

Rationale: Lack of visibility is considered critical, so that users do 
not become confused by the variability in the set of security services 
they are being afforded. An application that has not mandated explicit 
use of security protocol benefits from opportunistic security, but OUGHT 
NOT [RFC6919] make decisions on how to behave based on the success or 
failure of OS mechanisms.

2.Opportunistic security is not intended to be a substitute for

authenticated, integrity-protected encryption when that set of

security services can be provided to a user.

Rationale: This is linked to #1 above. If a user can establish a 
server-authenticated TLS session with a financial institution today, the 
user should continue to do so.This requires that users (applications) 
MUST still be able to explicitly invoke security protocols, and suggests 
that OS is not explicitly invoked.

3.Opportunistic security SHOULD (?) make use of key agreement (vs. key 
transport) and employ perfect forward secrecy (PFS).

Rationale: Key agreement (e.g., Diffie-Hellman or ECDH) is preferred 
over key transport because it can be effected without adding round trips 
to a protocol. Key agreement also is preferred because it readily 
supports PFS, if ephemeral keys are employed. In turn, PFS is desired 
because it affords protection against a range of attacks that go beyond 
simple, passive wiretapping.The recently noted "heartbleed" attack is 
capable of extracting keys from a server or client using TLS. If no long 
term private/secret keys are employed by OS, then an attack of this sort 
is limited in its impact.

4.Crypto-based authentication is a desired, but not mandatory,

feature.

Rationale: Authentication of the encrypted channel is desirable because 
it offers protection against a range of active attacks, including MiTM, 
that could cause a user to communicate with a party impersonating the 
intended communication target. Some security protocols mandate two-way 
crypto-based authentication, by default, e.g., IKE. TLS [RFC5246] and 
SSH [RFC4253] typically make use of 1-way (server-based) crypto-based 
authentication, although they also support client-based channel 
authentication. (Both Web PKI certificates and DANE TLSA records 
[RFC6698] are viewed as acceptable forms of cryptographic-based 
authentication.) Because the success or failure of opportunistic 
security is not to be signaled to the initiator of a session, the user 
will not know whether the target of the session has been authenticated.

5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not 
mandatory, feature.

Rationale: If crypto-based authentication is successful, it provides 
detection of a MiTM attack (subject to the veracity of the credentials 
employed.) However, even if such authentication cannot be achieved, it 
may still be possible to detect a MiTM.MiTM detection is considered a 
lower priority than authentication, and is to be pursued only if the 
former security service is not available (or fails). Again, if a MiTM is 
detected, this event is NOT signaled to the user/application.

6.In some contexts, human-perceptible delays in session/connection

establishment might discourage use of OS.In such contexts,authentication 
and MiTM detection SHOULD take place after an encrypted channel has been 
established.This ordering implies that some data may be transmitted 
prior to authentication or detection of a MiTM.In a context where delays 
imposed by performing authentication are not considered onerous, 
authentication MAY be attempted prior to enabling transmission.In such 
contexts all application traffic will be afforded authentication (and, 
typically, integrity) if available.

Rationale: The first sentence provides the rationale, i.e., we don't 
want delays imposed by authentication (or MiTM detection) to deter use 
of OS.

7. An attempt to create an opportunistically securemay fail, resulting 
in plaintext communication.

Rationale: OS usually will require changes to existing protocols, or 
development of new protocols. Thus an attempt to establish an OS-based 
session, may fail, because the target of the session does not support OS.

Thus, until OS is universally adopted, an attempt to execute opportunistic

security may result in plaintext communication.Since an attempt to use 
opportunistic security is not communicated to users or applications, 
falling back to the status quo, i.e., plaintext communication, is a 
reasonable strategy.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Apr 2014 19:36:48 +0000

On Mon, Apr 14, 2014 at 03:19:55PM -0400, Stephen Kent wrote:

> I reported that a breakout session at the STRINT workshop identified several
> features that should be part of opportunistic security. It has been
> suggested that at least one of these, PFS, ought not be mandatory. I suggest
> we explicitly review all of the proposed features for OS and decide which
> are mandatory, which are optional, and which have no place in a definition
> for OS.

My take is that we need a more precise definition of "mandatory".

    - Mandatory to implement?
    - Mandatory to prefer?
    - Mandatory to use (negotiate)?

At least with PFS, one might reasonably argue for the first two,
but requiring PFS use seems rather contrary to the "opportunistic"
mind-set of doing the best you can.  If the peer only offers RSA
key transport, then that's what you go with.  The peer's configuration
is then not marketable as fully "OS" enabled.

> 3.  Opportunistic security SHOULD (?) make use of key agreement (vs. key

Here, I would strongly suggest that being "opportunistic" the SHOULD
only covers "implementation" and "preference" for PFS, but does
not imply any mandate to use PFS (or else refuse to encrypt? Really???).

> employed.) However, even if such authentication cannot be achieved, it may
> still be possible to detect a MiTM.MiTM detection is considered a lower
> priority than authentication, and is to be pursued only if the former
> security service is not available (or fails). Again, if a MiTM is detected,
> this event is NOT signaled to the user/application.

The above is a bit too restrictive for "opportunistic DANE TLS",
where one strives for downgrade resistance when possible, and may
well signal authentication failure to the user/application.  Of
course the application needs to elect this mode of operation
(opportunistic with DANE).

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2014 10:12:42 -0400

Viktor,

On 4/14/14 3:36 PM, Viktor Dukhovni wrote:
> ...
Good question in the current environment.
I'm old school IETF, so mandatory means mandatory to implement.
Preferences and decisions to use are local matters.
> not imply any mandate to use PFS (or else refuse to encrypt? Really???).
Again, implementation.
> (opportunistic with DANE).

I think this needs to be discussed in a general context, not just for
the cited example. A lot of folks seemed to feel strongly that the 
success or
failure of opportunistic security ought bot be made visible to users/apps.
Maybe they were thinking more about users than apps, and thus this feature
should be tempered with that in mind. There was also a brief discussion 
of whether
a server should be notified when a failure (authentication or MiTM 
detection)
occurs, vs. silent acceptance on behalf of a client.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Apr 2014 14:33:45 +0000

> Preferences and decisions to use are local matters.

Thanks for the clarification.  In that case, at least for TLS, the
issue is largely moot.  All actively maintained TLS toolkits
*implement* PFS key exchange.  In the case of OpenSSL, for example,
the default cipher list ordering prefers ephemeral ECDH and prime
DH to RSA key transport (even when the server key is an RSA key).

So in that light, there is no friction between a PFS requirement
for OS and opportunistic uses of TLS.

To get RSA key transport, a server administrator has to intervene
with a non-default cipher list setting and to impose server-side
cipher preference over the default choice of the client's most
preferred cipher-suite that is also supported by the server.  In
some cases clients offer cipher lists that suppress PFS or prefer
RSA key transport.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Apr 2014 05:06:36 +0000

> Here is the list I recall from the workshop, with a rationale for each

Question, is the STRINT workshop (or specifically the break-out
session) a normative or informational source for this discussion?

In other words, apart from using STRINT material as a potential
source of good ideas, are we bound to adhere to its recommendations?

> 1.  OS is invisible to users, and, more broadly, to applications that
> initiate sessions.

Perhaps "invisible" is too strong a constraint.  Minimally-intrusive
may come closer to the mark.  If we don't set the ceiling at
protection against passive eavesdropping and allow OS mechanisms
to discover stronger security policy via DANE or similar protocols,
then:

    - When no stronger than default out of band policy is discovered,
      failure to encrypt or authenticate does not interrupt the
      application's or user's work-flow.

    - However, when stronger policy is discovered, failure to
      achieve the discovered policy level may indeed be treated in the
      same way as failure to achieve a-priori (non-opportunistic) strong
      policy.

    - We should perhaps not pre-judge what may or may not be confusing
      to users in terms of signalling the security level.  This should
      be left to application designers.  Applications may want to use
      passive signalling to indicate cleartext vs. unauthenticated
      encryption vs. authenticated encryption via some discovered policy.
      Such signalling via a passive UI element if designed appropriately
      should not be excluded by the definition of OS.

The web browser is not the only possible application, it is simply
the one of the most complex, and its security user-interface design
is neither universal nor yet perfected.

We should not assume an unauthenticated ceiling for OS.  Some application
protocols will admit opportunistic security policies with a broader range
than merely:

    * cleartext, or else, when possible
    * unauthenticated encryption to thwart passive eavesdropping

> security services can be provided to a user.

Absolutely, for example, Postfix after DANE still has PKIX support
and also a new "dane-only" policy which requires DNSSEC validated
TLSA RRs for destinations subject to that policy.

	http://www.postfix.org/TLS_README.html#client_tls_levels

And per the previous comment, nor is OS necessarily unauthenticated,
or vulnerable to downgrade and MiTM attacks.  The key feature of
OS is a spectrum of possible outcomes ranging potentially from
cleartext (if the protocol or application must inter-operate with
legacy cleartext-only peers) to fully authenticated encrypted sessions,
with the outcome dependent on the peer's advertised capabilities.

OS is adaptive, and does the best it can with each peer.  This
"best available" policy might be negotiated via a downgrade vulnerable
protocol, (e.g. SMTP STARTTLS) or via a downgrade-resistant protocol
(e.g. DANE TLSA via DNSSEC).  Downgrade resistant negotiation may
fail in the face of active attacks, and the application should then
not simply ignore the problem, appropriate exception handling needs
to be performed in that case (defer the mail, log warnings recording
possible MiTM and send anyway, interact with a user via noisy
dialogues, ...).

In other words, just because STRINT participants did not envision
downgrade-resistant opportunistic authenticated encryption, does
not mean that the OS definition should exclude such protocols.
Perhaps more strongly OS protocols SHOULD strive for higher security,
when reasonably compatible with the application protocol.

Don't *just* resist passive eavesdropping, let's deploy flexible
security protocols that interoperate at multiple security levels.
Initially things like the DANE for SMTP protocol will still be
rare, but if we can get traction with DNSSEC and DANE, perhaps some
day we can have opportunistic security that is in some ways stronger
than current mandatory security mechanisms.

> transport) and employ perfect forward secrecy (PFS).

To be less ambiguous, as discussed, we should say "implement and
prefer" or some such.  Actual "use" may be gated on peer capabilities,
...

> 4.Crypto-based authentication is a desired, but not mandatory,

May be mandatory when discovered, but exception mechanisms (log
warning, prompt user, ...) may be available in some applications,
just as they are for existing mandatory security policies.

> 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not

See above.

> 7. An attempt to create an opportunistically secure may fail, resulting in
> plaintext communication.

If that's the floor for the protocol in question.  If some future protocol
is defined only over TLS or similar, then cleartext might be excluded,
and the range may be from "unauthenticated" to "authenticated", but always
encrypted.

> opportunistic security is not communicated to users or applications, falling
> back to the status quo, i.e., plaintext communication, is a reasonable
> strategy.

Indeed, but "status-quo" (or more to the point least secure comms mechanism
for protocol in question) is not necessarily unencrypted.

I think think brings us back to Nico's suggestion to take a stable
at a higher level definition of OS, not in terms of a list of
properties, but in terms of a philosophy:

    - Universal interoperability, able to connect to all peers, even those
      configured for minimal to no security.  Unintrusive security that
      broadly works, when the peer is not outright misconfigured.

    - Opportunistic use of available security mechanisms.  Encrypt when
      possible, authenticate when possible, downgrade-resistant when
      possible, ...

I tend to phrase this in the more cryptic form of "no floor, no ceiling",
but that is too opaque without a detailed explanation.

Nico's definition for reference/comparison:

    You get the strongest security in the Internet threat model
    that can be obtained, and you get as strong a floor on security
    in the Internet threat model as that which you can securely
    discover, else the floor may be as low as protection only
    against passive attacks.

We're saying the same thing I think.  His is more succinct than
this message, I hope I've been able to clarify rather than merely
repeat the idea.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Apr 2014 11:41:00 +0100

Hiya,

> session) a normative or informational source for this discussion?

Informative.

> source of good ideas, are we bound to adhere to its recommendations?

Not at all. It was a workshop. Source-of-good-ideas seems about
right to me, though of course there were 100 of the usual
suspects there so it was not a random source of good ideas.

That could be good or bad I guess:-) But mostly good in this
case I think.

S.

PS: Should have a -00 draft of the workshop report out later
this week or over the weekend.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2014 10:16:56 -0400

Viktor,
> session) a normative or informational source for this discussion?

It's informative. The workshop was not an IETF meeting, although it was
sponsored by ISOC, W3C, etc. Stephen noted that there were about 100 
attendees.
That's true, but I don't think that's as important as the fact that the 
folks
who developed this set of "features" included the current Sec ADs, chair of
UTA, a former Sec AD, the chair of the IETF, and a few others. The 
workshop as
a whole didn't generate or even approve of this list; it was a breakout 
session
with the attendees noted above (and several others) that generated it. 
But, that
set of attendees is very knowledgeable and thus the conclusions merit 
serious consideration.

Also I just wanted to note that this set of features was not something that
I invented :-).
> source of good ideas, are we bound to adhere to its recommendations?
the former.
>        application's or user's work-flow.

certainly.
>        same way as failure to achieve a-priori (non-opportunistic) strong

what's a policy here? Is the policy an advertised set of security 
capabilities,
as suggested later, communicated via the DNS?
>        should not be excluded by the definition of OS.

Most app designers (present company excluded, of course) have a poor 
history
of managing UIs wrt security, so I am not enthusiastic about the last 
bullet above.
Also, what is "passive signalling?"

> is neither universal nor yet perfected.

agreed.
>      * unauthenticated encryption to thwart passive eavesdropping

The primary rationale provided for OS is the second bullet above.
Thus having OS focus on that seems reasonable.
> with the outcome dependent on the peer's advertised capabilities.

You stated an assumption at the end which is not consistent with what
I have heard many folks assume, i.e., that the target of a session
advertises it's security capabilities. I don't disagree that one could
choose to operate this way, but it has not been an agreed-upon part of the
opportunistic * discussions in general. I suspect the reason is that the
more prerequisites we impose on OS, the longer it will take to deploy.

> possible MiTM and send anyway, interact with a user via noisy

If we defer an action because we have detected an active attack, a
user is inconvenienced. If users are inconvenienced, they may decide
that a service they didn't ask for is an annoyance, and thus they
might demand that it be disabled. This potential outcome runs counter
to the primary goal of increasing use of encryption. So, I think many
folks have emphasized the need for an OS design that is not intrusive,
i.e., essentially painless.

> when reasonably compatible with the application protocol.
A less pejorative explanation is that the participants felt that maximizing
deployment of encryption was the most important goal :-).
> than current mandatory security mechanisms.
Stronger? TLS, DTLS, and IPsec are very strong protocols. There are
all capable of supporting PFS, and can use a variety of strong 
authentication
mechanisms. Providing very widely deployed resistance to passive wiretapping
seems to be the primary goal of OS. If authentication can be achieved, 
without
imposing unacceptable delays, then it is a great extra feature. That's how I
have heard many folks characterize OS goals.

> prefer" or some such.  Actual "use" may be gated on peer capabilities,

SHOULD captures the community-based flexibility to which you refer.
If we want to say it is preferred, we just need to say that. I'll make
that change in the next rev.
> just as they are for existing mandatory security policies.
Again, what is meant by "discovered"? If an app performs authentication,
instead of a security protocol, that is a separate topic. Maybe I am
misunderstanding your intent here.
> and the range may be from "unauthenticated" to "authenticated", but always
If a protocol is defined to operate only over TLS, then it gets whatever
set of TLS features are offered/negotiated. TLS is a security protocol,
and I though the term "OS" is supposed to refer to secruity protocols. So,
an app running over TLS would not be an example of OS.
> for protocol in question) is not necessarily unencrypted.
the status quo that motivates OS is unencrypted.
>        configured for minimal to no security.

Yes, universal interoperability is a good feature to add, explicitly.
I'll add it.

> Unintrusive security that

"broadly works" isn't very clear., at least to me. Since a peer
may not support OS, how is misconfigured different from not supported?
>        possible, authenticate when possible, downgrade-resistant when

encrypt when possible is the fundamental requirement, so it seems
redundant here. I think there is too much focus on "available
security mechanisms" in the text above.
> but that is too opaque without a detailed explanation.

yes, way too opaque.
> this message, I hope I've been able to clarify rather than merely

Sorry, but as I mentioned in my reply to Nico, the long sentence above is
not at all clear. Succinctness is a virtue only if clarity survives.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 17 Apr 2014 16:07:17 +0000

On Thu, Apr 17, 2014 at 10:16:56AM -0400, Stephen Kent wrote:

[ First quoted block moved to the top for emphasis.  This is absurd.
  If arguments along these lines continue, I will be forced to withdraw
  my "go for it" vote, and will suggest that others do likewise, on
  the basis that the current author/editor is doggedly obstructing
  progress. ]

> and I though the term "OS" is supposed to refer to security protocols. So,

Of course "opportunistic security" applies with TLS.  Authentication
is optional in TLS, even when certificates are exchanged, either
or both parties can simply ignore them or use any of a number of
non-PKIX mechanisms to validate them.

If we exclude TLS, we push out adoption of "OS" to some nebulous
future when all applications have migrated to new channel security
protocols.

> capabilities, as suggested later, communicated via the DNS?

Yes, that's what I mean, perhaps some word other than "policy"
would be better, but I've been going with "policy" for the purpose
of this discussion.

> Most app designers (present company excluded, of course) have a poor history
> of managing UIs wrt security, so I am not enthusiastic about the last bullet
> above.

Sure, but well thought out UIs should not be discouraged from
communicating more a more nuanced security status unambiguously to
an appropriate set of users.

> Also, what is "passive signalling?"

Anything along the lines of a colour element or a "lock icon" that
is unobtrusive, unlike a dialogue box that demands attention and
interaction.

> Thus having OS focus on that seems reasonable.

The "focus" must not be too narrow.  OS needs to *at least* deal
with pervasive monitoring, but a broader definition that covers
that use case and more is even better.

The core philosophy I'm proposing for OS is to maximize interoperable
security.  OS clients will interoperate with all peers, absent
active attacks, peer misconfiguration or peer implementation bugs.

The minimal profile, is just unauthenticated encryption with fallback
to cleartext when that is the default peer capability.

With opportunistic DANE TLS (or other dynamically discovered
capabilities (peer policies)) the connection may be authenticated,
and fallback may be avoided to thwart active downgrade attacks.

In other words, while STRINT focused squarely on addressing pervasive
passive monitoring, the definition of "opportunistic security"
should be broader, and should cover opportunistic protocols with
higher ceilings.

> advertises it's security capabilities.  

    * Not an assumption, a use-case.  Some opportunistic security
      protocols will have more information to work with than others.

    * For fallback to be possible, some kind of 'advertisement' is
      inevitable.  It could be "STARTTLS".  It could be a SRV RRset.
      It could be listening on a well known port where one expects
      a secured variant of the same service...

> I don't disagree that one could

I repeat:  I am NOT suggesting OS *requirements*.  I am suggesting
that "opportunistic security" is an "umbrella term", which will
cover a range of technologies with some core similarities in their
approach to security.  The term "opportunistic security" does NOT
describe a single protocol.

I am merely insisting that the term be defined broadly enough to
make space for a range of protocols, some of which will have
additional properties that are NOT required for OS, but are
in fact compatible with the umbrella term.

Where an OS protocol with a higher ceiling is a good fit for a
particular application protocol, I'd like to encourage the adoption
protocols that don't set the ceiling too low.  However, such efforts
must not derail broad adoption of best effort to at least thwart
passive eavesdropping.

Thus for SMTP opportunistic DANE TLS operates at multiple levels:

    - Cleartext for peers with no TLSA RRs and no "STARTTLS".

    - Unauthenticated encryption for peers with "STARTTLS" only.
      Many implementations fall back to cleartext when the TLS
      handshake fails with such a peer.

    - Mandatory unauthenticated encryption for peers with a TLSA
      RRset, where the advertised parameters are not usable for
      authentication, but the mere presence of the TLSA RRset
      commits the peer to implement TLS.

    - Mandatory authenticated encryption for peers with a usable
      TLSA RRset.

This mode of operation maximizes security against both passive and
active attacks.  We don't fail to encrypt, just because authentication
is not possible, but we also don't fail to authenticate when
possible, just because authentication is not possible with many/most
peers and by default we try to at least encrypt.

The above is definitely "opportunistic security" and while the model
goes beyond the STRINT focus on dealing with pervasive passive
monitoring, it is not at odds with the goals of STRINT and more
importantly it meets a reasonable more expansive definition of the
umbrella term "opportunistic security", which needs to be broader
than just a response to passive monitoring.

> user is inconvenienced.  

Because the user explicitly enabled a security mechanism that
detects active attacks.  In Postfix the "dane" security level is
NOT forced on MTA administrators, they need to turn it on and can
set it either as a default level for all destinations, or the
security level for some subset of destinations.

> If users are inconvenienced, they may decide
> might demand that it be disabled.

I did not say that the user "did not ask for" the hardened variant
of opportunistic security, that's your assumption.

> This potential outcome runs counter to the primary goal of increasing
> use of encryption.

If only that were the problem!  What is the point of encryption
that one knows is actually subverted by a man in the middle attack?

The primary goal is to frustrate passive eavesdropping, and certainly
if a candidate protocol is subject to lots of authentication failure
false positives (sans active attack), then it may discourage use, to
the detriment of the primary goal.

However, if a candidate protocol delivers robust unauthenticated
encryption, and a sufficiently low FP rate, and one can configure
fallback policies for authentication failure which, for example,
lead to unauthenticated encryption with a warning when authentication
that should have worked fails, then it is reasonable to try to reach
a higher ceiling.

> So, I think many

The many folks in question, have not considered all possible
use-cases, for opportunistic security.  They are still thinking
primarily of their grand-parents using a browser, and in that case,
perhaps for now only the least ambitious approaches are viable.

However, you're not writing a design-spec for a browser security
policy.  You're writing a definition of "opportunistic security",
which MUST be able to go beyond grandpa's browser use-case.

I expect you'll find that "folks" on this forum will broadly support
the idea that "opportunistic security" is an "umbrella term" and
not just a counter-measure to a single problem.

> deployment of encryption was the most important goal :-).

This is a spurious argument, because you're still arguing against
including higher ceilings as required features of OS, while all I
am asking for is *not excluding* higher ceilings from the definition
of a term that subsumes multiple protocols, some of which might
well be as unambitious in their security ceiling as you suggest.

> Stronger?

In some ways, specifically the difference between PKIX and DNSSEC
with respect to who can issue certificates for which domains.  Anyway,
this is not the point.

> Providing very widely deployed resistance to passive wiretapping
> seems to be the primary goal of OS.

NO!  The term "opportunistic security" MUST be an "umbrella term"
for a collection of protocols, all of which share the trait of not
throwing out the baby with the bath-water when their security ceiling
cannot be reached.  They adaptively operate at multiple security
levels, opportunistically achieving the highest level applicable
for a given peer.

> If authentication can be achieved, without

Please adopt a more flexible definition of "OS" or allow others to
do so.  "OS" is a not a single protocol for a single application.
"OS" is a set of principles for a new adaptive approach to security,
which strives to maximize the security level achieved without
excluding the majority of peer systems for lack of a maximally
secure channel.

> misunderstanding your intent here.

Discovered, means dynamically determined via interaction with
external information sources.  Thus with "opportunistic DANE TLS",
authentication applies some destination domains and not others,
and may apply to a domain at one time (when TLSA records are
published) and not at another time (when they are not yet or no
longer published).

Opportunistic here means that authentication applies when the
relevant capabilities are discovered.

> the status quo that motivates OS is unencrypted.

Primary motivating cases are a good thing to have, but one then
needs to be willing to remove blinders and leave room for additional
relevant use-cases.

> may not support OS, how is misconfigured different from not supported?

Since "OS" is not an application protocol, it makes little sense
to speak of peers not supporting it.  Peers speak valid variants
of the application protocol, some more secure than others.

Misconfigured means unable to speak the application protocol
correctly, which includes, as a special case, unable to deliver on
the advertised security parameters.

Opportunistic security works with properly configured peers at
multiple security levels absent MiTM attacks.

> not at all clear. Succinctness is a virtue only if clarity survives.

Please suggest a less succinct, more clear formulation.

-- 
	Viktor.