On Wed, Aug 06, 2014 at 11:55:53AM -0400, Rene Struik wrote:
(b) The verbiage in the draft should make it more clear that opportunistic
encryption will not jeopardize those entities that wish to only set-up
secure and authentic channels, by policy.
Where local or other policy (e.g. semantics of HTTPS URIs) requires
both active and passive protection, opportunistic security is not
in scope.
However, it is worth quoting from the draft that the effect of the
high bar set by current designs is that most traffic is not protected
at all. Opportunistic security aims to provide some (in fact as
much as possible) security (be it just channel protection) to the
huddled masses. Ideally, often essentially as strong as the
statically defined comprehensive protections in extant protocols,
but now on a peer by peer basis, enabling "incremental adoption".
[ Steve Kent: that's what I meant to say by "organic", sorry about the
inadvertent associations with manure, the word "organic" does not
appear in the draft, only in my email comments, the right word is
"incremental". ]
Essentially, there are three
channel categories: (i) unsecured channel; (ii) channel providing
confidentiality only; (iii) channel providing confidentiality and
authenticity.
Yes, ignoring some sub-categories, essentially three possible
*outcomes*. However, there are also multiple possible prior
policies that lead to one of the afore-mentioned outcomes:
* Channel security off
* Channel security fixed to only encrypt
* Channel security fixed to encrypt and authenticate
* Channel security adaptive to peer capabilities finding the *maximum*
possible with a given peer.
The last of these is essentially opportunistic security. In real
applications, the prior policy might also be peer-dependent. So
that for example one might default to OS for a generic peer, but
set a high bar for some peers statically (potentially requiring
some bilateral policy coordination with administrators of the peer
system).
While opportunistic security aims to enable a shift from (i)
to (ii),
or for some combinations of peers (i) to (iii).
it may also cause a shift from (iii) to (ii)
OS does not trump local or protocol requirements. It aims to secure
to the extent possible, the under-served population left out in the
cold by a binary choice between (i) and (iii).
If OS adoption leads to users abandoning protocols or configurations
that require (iii) in favour of more adaptive approaches, then
perhaps users did not want (iii) as much as security engineers and
protocol designers thought they did.
-- There should be language in draft 02 that expresses this concern (which
would be a security loss), e.g., with the security consideration section.
OS itself does not degrade security. That would only happen if users choose
to disable prior policies that require active protection and replace these
with OS. OS does not aim for users to do that, but if they do, it is not
clear that OS is doing the user a disservice.
-- The current language re "design for interoperability" leaves ambiguity as
to whether one cares about channels where one would like to enforce, by
security policy, channel category (iii).
The SMTP opportunistic DANE TLS draft mentions coexistence of that
protocol along-side existing channel security policies. We can
add some language that makes it clear that OS is not intended to
displace cases where security assurance is required, rather it is
intended to serve the under-served.
Currently, the phrase
"interoperability must be possible without a need for the administrators of
communicating systems to coordinate security settings" suggests that a
system where one authenticates entities via certificate verification of a CA
root key acceptable to the receiving end of a communicated cert would be
taboo
Opportunistic security needs to allow "incremental" adoption,
without O(N^2) manual coordination effort. For use-cases where
use of public CAs requires no manual coordination, OS can use public
CAs. In any case, OS does not exclude the use of non-OS policies
where applicable.
Just because something is not OS, does not mean that it is forbidden.
It is simply not OS.
-- What about the following change at end of the section on
"interoperability" (first para of Section 3): replace by "Opportunistic
security must not get in the way of the peers communicating if neither end
is misconfigured and neither end precludes communicating with the other end
by virtue of its own security policy".
On the substance, sure, but if we're going to have to explain this,
I'd like to do it elsewhere, by stating that OS does not trump
local or other policy that requires greater channel security for
some or all peers. Such policy is not OS, but OS can coexist along-side
other (traditional or new mechanisms or policies).
Note: Right now, the term
"misconfigured" is not really defined, but the suggestion from the entire
draft is that one should allow channel type (ii), no matter what.
For peers only capable of (ii), when some OS protocol is the selected security
mechanism. I wanted to define OS. It seems I am being asked to also define
how it interacts/coexists with other designs.
(c) With the "maximize security peer by peer" para (Section 3), the phrase
"opportunistic security may at times refuse to operate with peers for which
higher security is expected, but for some reason not achieved" is somewhat
cryptic. If the intention is to capture that ultimately it is up to each
peer to enforce its own security policy as to channel category (i), (ii),or
(iii),
No, this is mostly about the purported capabilities of the peer,
not (static) prior policy. We can handle static policy separately
if that's required.
--
Viktor.