Re: [saag] OS features/requirements analysis

[Viktor Dukhovni <[e-mail]>]

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. ]

> 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 security protocols. So,
> an app running over TLS would not be an example of OS.

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.

> >     - 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.
> 
> what's a policy here? Is the policy an advertised set of security
> 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.

> >     - 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.
> 
> 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.

> >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
> 
> The primary rationale provided for OS is the second bullet above.
> 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.

> 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.  

    * 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
> 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.

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.

> If we defer an action because we have detected an active attack, a
> 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
> that a service they didn't ask for is an annoyance, and thus they
> 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
> folks have emphasized the need for an OS design that is not intrusive,
> i.e., essentially painless.

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.

> >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.
>
> A less pejorative explanation is that the participants felt that maximizing
> 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.

> >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.
>
> 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
> imposing unacceptable delays, then it is a great extra feature. That's how I
> have heard many folks characterize OS goals.

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.

> >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.
>
> 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.

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.

> >Indeed, but "status-quo" (or more to the point least secure comms mechanism
> >for protocol in question) is not necessarily unencrypted.
>
> 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.

> "broadly works" isn't very clear., at least to me. Since a peer
> 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.

> >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.
> 
> 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.

Please suggest a less succinct, more clear formulation.

-- 
	Viktor.