Subject: [saag] Review of - draft-dukhovni-opportunistic-security-04

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Aug 2014 13:44:08 -0700

Review of:     Opportunistic Security: Some Protection Most of the Time
I-D:           draft-dukhovni-opportunistic-security-04

Reviewed by:   D. Crocker
Review date:   26 Aug 2014

Summary:

   The paper defines and explains flexible approach to the use of
encryption on the Internet.  It assigns the term 'opportunistic
security' to this term.

   The latest draft has extensive changes from the previous version.

   Although many of the changes are quite helpful, the document still
suffers from confusing or unexplained terminology and some unfortunately
initial organization.

   A number of points from previous reviews have not been addressed.

   The paper continues to freely make strong assertions, without
providing any substantiation or even, in some cases, explanation.  At a
minimum, every term that is used, every assertion that is made and
anything else that derives from Internet experience should be documented.

   Concerns with the term "opportunistic security" persist.  It is both
vague and overblown, given the specific technical point it is meant to
address.  That concern is about encryption and the term should make that
clear.

   The paper still needs extensive revision before it should be
considered for publication.

A global editorial nit to consider:

   "Peer" is a potentially problematic term, for interactions that are
mediated.  The term "participant" does not suffer this exposure.

   So:

     s/peer/participant/g

although "other participant" in some cases.

Detailed Comments:

> Abstract
> 
>    This document defines the concept "Opportunistic Security" in the
>    context of communications protocols.  Protocol designs based on
>    Opportunistic Security remove barriers to the widespread use of
>    encryption on the Internet by using encryption even when
>    authentication is not available, and using authentication when
>    possible.

The summary cites an outcome that is far from certain.  Whether it will
remove barriers is a hope, not a certainty.

An abstract that is more in the style of a technical document and less
in the style of a marketing document, requires only small changes:

      "Opportunistic Security" (OS) refers to the use of encryption
even when authentication is not available, and use of authentication
when possible. It is hoped that designing protocols and procedures to
have the flexibility of an OS approach will result in more pervasive use
of encryption.

> 1.  Introduction
> 
>    Broadly speaking, Opportunistic Security (OS) is a pragmatic risk
>    management approach.  With Opportunistic Security, one applies the
>    tools at hand to mitigate the risks that can reasonably be addressed,
>    and accepts the rest.

Delete this paragraph.  First, it's wrong.  It's not a 'risk management'
approach.  Risk management is a term of art that does not apply here.
Second, the paragraph adds nothing.

If anything, OS is about attacks or threats and not risks.

In addition, the Introduction should do some introducing.  It needs to
start with a description of the problem or issue or...  That is, the
kind of stuff that is now in Section 1.1.  I suggest making /it/ be the
Introduction, with this one following it.  (As an alternative, there's a
less traumatic suggestion farther down.)

>    Definition:  In the context of communications protocols,
>       "Opportunistic Security" is defined as the use of encryption when
>       possible, with authentication when possible.  In the above, the
>       phrase "when possible" means when support for the corresponding
>       capability is advertised by the peer, ideally in a downgrade-
>       resistant manner.

The definition looks pretty good.  Seeing that it includes cleartext
requires some thought.  And the idea still seems pretty odd (ie, silly)
in the context of seeking more use of encryption.

> 1.1.  Background

For each assertion made in this section, there should be a citation to
substantiate it.  Since these assertions provide the justification for
doing OS, it's important to /document/ a solid case against the existing
choices.

More broadly, when citing a technology or standard or convention, cite
something that explains it in detail.  As an example, TOFU (which would
be nicely handled by pointing to the terminology section).

> 
>    Historically, Internet security protocols have emphasized
>    comprehensive "all or nothing" cryptographic protection against both
>    passive and active attacks.  With each peer, such a protocol achieves

"With each peer" does not have an obvious meaning and it isn't needed.
Delete the phrase.

>    either full protection or else total failure to communicate (hard
>    fail).  As a result, operators often disable these security protocols
>    when users have difficulty connecting, thereby degrading all
>    communications to cleartext transmission.
> 
>    Protection against active attacks requires authentication.  The
>    ability to authenticate any potential peer on the Internet requires

"potential" is extraneous or worse.  The issue is authenticating
/actual/ participants.  So just say "any participant".

>    an authentication mechanism that encompasses all such peers.  No IETF

delete "authentication".

>    standards for authentication meet this requirement.

This is written rather indirectly.

Instead:

   Protection against active attacks requires the use of authentication.
 However no authentication mechanism is yet in use at Internet scale.
The primary barriers are believed to be key management and human factors.

>    The Public Key Infrastructure (PKI) model employed by browsers to

To repeat from the previous review:  It's not just by browsers.

>    authenticate web servers (often called the "Web PKI") imposes cost
>    and management burdens that have limited its use.  With so many

"With so many" asserts a fact not introduced yet, so it presumes
knowledge the reader might not have.

Instead:

   There are many certification authorities, ...

>    certification authorities, which not everyone is willing to trust,

   trust, the -> trust, and the

>    the communicating parties don't always agree on a mutually trusted
>    CA.  Without a mutually trusted CA, authentication fails, leading to
>    communications failure in protocols that mandate authentication.

new paragraph, since you are introducing a separate point about key
management.

>    These issues are compounded by operational difficulties.  For
>    example, a common problem is for site operators to forget to perform
>    timely renewal of expiring certificates.  In interactive
>    applications, security warnings are all too frequent, and end-users
>    learn to actively ignore security problems, or site administrators
>    decide that the maintenance cost is not worth the benefit so they
>    provide a cleartext-only service to their users.

Typically, 'user interface design' issues are not folded into the term
"operations".  Usually, end-user issues are distinct from ops.

>    The trust-on-first-use (TOFU) authentication approach assumes that an
>    unauthenticated public key obtained on first contact (and retained

I can't find any other occurrence of "unauthenticated public key"
through google and am not exactly sure what it means.  For a paper like
this, that should be a significant concern...

>    for future use) will be good enough to secure future communication.

  future -> continuing [ or perhaps further ]

>    TOFU-based protocols do not protect against an attacker who can
>    hijack the first contact communication and require more care from the
>    end-user when systems update their cryptographic keys.  TOFU can make
>    it difficult to distinguish routine system administration from a
>    malicious attack.

Huh?  The basis or accuracy of that last sentence isn't at all obvious
to me.

>    DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a
>    way to distribute public keys bound to DNS names.  It can provide an
>    alternative to the Web PKI.  DANE needs to be used in conjunction
>    with DNSSEC [RFC4033].  At the time of writing, DNSSEC is not
>    sufficiently widely deployed to allow DANE to satisfy the Internet-
>    wide, any-to-any authentication requirement noted above.  Protocols
>    that mandate authenticated communication cannot yet generally do so
>    via DANE (at the time of writing).
> 
>    The lack of a global key management system means that for many
>    protocols, only a minority of communications sessions can be
>    predictably authenticated.  When protocols only offer a choice
>    between authenticated-and-encrypted communication, or no protection,
>    the result is that most traffic is sent in cleartext.  The fact that
>    most traffic is not encrypted makes pervasive monitoring easier by
>    making it cost-effective, or at least not cost-prohibitive (see
>    [RFC7258] for more detail).
> 
>    For encryption to be used more broadly, authentication needs to be
>    optional.  The use of encryption defends against pervasive monitoring

   against pervasive monitoring
   ->
   against some forms of pervasive monitorying

As Bernard Aboba's posting observed, it's not necessarily all that
strong a protection against PM...

>    and other passive attacks (which are employed not only by nation
>    states).  Even unauthenticated, encrypted communication (defined
>    below) is preferable to cleartext.
> 

As an alternative to moving sections around, with a tiny modification,
the above two paragraphs would make an excellent opening for the
Introduction.

The modification is:

   The lack of a global key management system means
   ->
   A global key management system is essential for enabling pervasive,
authenticated encryption.  Its lack means...

>    For some applications or protocols the set of potential peers
>    includes a long tail of implementations that support only cleartext.
>    Such applications or protocols cannot set a baseline security policy
>    that requires encryption without losing the ability to communicate
>    with the cleartext-only peers.
> 
> 1.2.  A New Perspective

It's hardly new.  de facto use of encryption without (meaningful)
authentication has been around for a very long time.

>    This document proposes a change of perspective.  Until now, the

More like:

   There have been ad hoc methods of allowing encryption without
meaningful authentication.  This paper seeks to acknowledge the efficacy
of that alternative and encourage designs that permit its use in a
flexible approach for encryption mechanisms.

>    protocol designer has viewed protection against both passive and
>    active attacks as the default, and anything short of that as
>    "degraded security" or a "fallback".  Now, with OS, the new viewpoint
>    is that without specific knowledge of peer capabilities (or
>    applicable local policy), the default protection is no protection,
>    and anything more than that is an improvement.
> 
>    Cleartext, not comprehensive protection, is the default baseline.  An
>    OS protocol is not falling back from comprehensive protection when
>    that protection is not supported by all peers; rather, OS protocols
>    employ the maximum protection possible.  OS protocols work
>    transparently behind the scenes, without disrupting communication.
> 
>    When less than complete protection is negotiated, there is no need to
>    prompt the user with "your security may be degraded, please click OK"

Even with the earlier discussion the paper needs to acknowledge, here,
the significant exposure this creates.

>    dialogs.  The negotiated protection is as good as can be expected.
>    Even if not comprehensive, it is often better than the traditional
>    outcome of either "no protection" or "communications failure".

> 3.  Opportunistic Security Design Principles
> 
>    OS provides a near-term approach to counter passive attacks by
>    removing barriers to the widespread use of encryption.  OS offers an
>    incremental path to authenticated, encrypted communication in the
>    future, as suitable authentication technologies are deployed.  OS
>    promotes the following design principles:
> 
>    Coexist with local policy:  Local security policies preempt OS.
>       Opportunistic security never displaces or preempts local policy.
>       Many applications and types of data are too sensitive to use OS,
>       and more traditional security designs are appropriate in such
>       cases.
> 
>    Emphasize enabling communication:  The primary goal of OS is to
>       enable communication and maximize the deployment of usable

The 'maximize' part is probably correct.  The 'enable' part is not.  Any
protocol 'enables' communication.  OS doesn't 'enable' communication. At
best, it avoids /dis/abling communication.

>       security.  OS protocols need to be deployable incrementally, with
>       each peer configured independently by its administrator or user.

It is not at all obvious what "deployed incrementally" means here.  This
needs to be explained carefully.  And I believe I made this point in a
previous review.

>    Maximize security peer by peer:  OS protocols use encryption when it
>       is mutually supported.  OS protocols enforce peer authentication
>       when an authenticated out-of-band channel is available to provide
>       the requisite keys or credentials.  Communication should generally
>       be at least encrypted.  OS should employ Perfect Forward Secrecy
>       (PFS) wherever possible in order to protect previously recorded
>       encrypted communication from decryption even after a compromise of
>       long-term keys.
> 
>    No misrepresentation of security:  Unauthenticated, encrypted
>       communication must not be misrepresented to users or in
>       application logs of non-interactive applications as equivalent to
>       authenticated, encrypted communication.
> 
>    An OS protocol first determines the capabilities of the peer with
>    which it is attempting to communicate.  Peer capabilities may be
>    discovered by out-of-band or in-band means.  (Out-of-band mechanisms
>    include the use of DANE records or cached keys or credentials

   credentials acquired -> credentials previously acquired

>    acquired via TOFU.  In-band determination implies negotiation between
>    peers.)  The capability determination phase may indicate that the
>    peer supports authenticated, encrypted communication;
>    unauthenticated, encrypted communication; or only cleartext
>    communication.
> 
>    Opportunistic security protocols may hard-fail with peers for which a

   may -> might

remove all RFC2119 reserved words

>    security capability fails to function as advertised.  Security
>    services that work reliably (when not under attack) are more likely

No kidding.

Really, it does not help to have this document state points that are
both secondary and obvious.

For the current point, I think what is actually meant is something like:

   Opportunistic Security is compatible with common protocol design and
operations quality criteria.

>    to be deployed and enabled by default.  It is vital that the
>    capabilities advertised for an OS-compatible peer match the deployed

Delete this sentence.  It's somewhere between irrelevant and silly.

That is, don't include basic lecture points on protocol or design
fundamentals.  Stay focused on the specifics of the paper's purpose.

And I believe this issue, too, was raised for earlier drafts.

>    reality.  Otherwise, OS systems will detect such a broken deployment

This has literally nothing to do with OS nor with "OS" systems.

>    as an active attack and communication may fail.  This might mean that
>    advertised peer capabilities are further filtered to consider only
>    those capabilities that are sufficiently operationally reliable.
>    Capabilities that can't be expected to work reliably should be
>    treated by an OS protocol as "not present" or "undefined".
> 
>    For greater assurance of channel security, an OS protocol may enforce
>    more stringent cryptographic parameters when the session is
>    authenticated.  For example, the set of enabled Transport Layer
>    Security (TLS [RFC5246]) cipher suites might be more restrictive for
>    authenticated sessions.

How is this relevant to OS, and what is it in the definition that would
lead one to expect it?

>    OS protocols should produce authenticated, encrypted communication
>    when authentication of the peer is "expected".  Here, "expected"
>    means a determination via a downgrade-resistant method that
>    authentication of that peer is expected to work.  

Huh?

We've already been told that authentication is to be used when possible.

The reference to "expected" doesn't make sense to me here and doesn't
seem to be adding anything useful to the paper.

>                                   Downgrade-resistant
>    methods include: validated DANE DNS records, existing TOFU identity
>    information, and manual configuration.  Such use of authentication is
> 
> 
> 
> Dukhovni                Expires February 26, 2015               [Page 7]
> 
> Internet-Draft           Opportunistic Security              August 2014
> 
> 
>    "opportunistic", in that it is performed when possible, on a per-
>    session basis.
> 
>    When communicating with a peer that supports encryption but not
>    authentication, any authentication checks enabled by default must be
>    disabled or configured to soft-fail in order to avoid unnecessary
>    communications failure or needless downgrade to cleartext.
> 
>    Cleartext is supported for backwards compatibility with systems
>    already deployed.  Even when cleartext needs to be supported,
>    protocol designs based on Opportunistic Security prefer to encrypt,
>    employing cleartext only with peers that do not appear to be
>    encryption capable.

Oh boy...

> 4.  Example: Opportunistic TLS in SMTP

This example is of unclear utility, since it mostly seems to be
documenting problems with the use of StartTLS and to rely on a reporting
of some 'current' deployment.

I'm not sure what point is being made by this section, but it seems that
it could be made more simply and more directly.

>    Most Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS

   Most -> Some

'Most' is not needed and it's not substantiated.  I'm even sure it's
correct.

>    ([RFC3207]) ESMTP extension.  MTAs acting as SMTP ([RFC5321]) clients
>    generally support cleartext transmission of email.  They negotiate

generally?  you mean, you know of any that don't???

   They ->  Some

>    TLS encryption when the SMTP server announces STARTTLS support.
>    Since the initial ESMTP negotiation is not cryptographically
>    protected, the STARTTLS advertisement is vulnerable to MiTM downgrade
>    attacks.
...

> 5.  Operational Considerations
> 
>    OS protocol designs should minimize the possibility of failure of

Does this mean that other designs don't have to worry about the issue?
That is, what is it that is specific to OS that warrants making this point?

>    negotiated security mechanisms.  OS protocols may need to employ
>    "fallback", to work-around a failure of a security mechanisms that is

Given the earlier, forceful claim that OS is a fall-forward, not
-backward, approach, this is confusing.

>    found in practice to encounter interoperability problems.  The choice
>    to implement or enable fallback should only be made in response to
>    significant operational obstacles.
...

> 6.  Security Considerations
> 
>    OS supports communication that is authenticated and encrypted,
>    unauthenticated and encrypted, or cleartext.  And yet the security
>    provided to communicating peers is not reduced by the use of OS
>    because the default OS policy employs the best security services
>    available based on the capabilities of the peers, and because local

I'm not entirely sure I'm parsing the above correctly, but the second
sentence appears to be asserting an unfounded conclusion.

>    security policies take precedence over the default OS policy.  OS is
>    an improvement over the status quo; it provides better security than
>    the alternative of providing no security services when authentication
>    is not possible (and not strictly required).

This sentence provides a nice example of why "security" is such an
unfortunate term, given that "encryption" is what is meant:  The use of
the word 'security' implies a broader sense of protection than is mean.

>    While the use of OS is preempted by a non-OS local policy, such a

  is -> can be

>    non-OS policy can be counter-productive when it demands more than
>    many peers can in fact deliver.  Non-OS policy should be used with
>    care, lest users find it too restrictive and act to disable security
>    entirely.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Tue, 26 Aug 2014 14:42:53 -0700

>    The latest draft has extensive changes from the previous version.

Sorry I didn't think of this sooner.

The wdiff between -03 and -04 is facinating.

Take a look at:

https://www.ietf.org/rfcdiff?url1=draft-dukhovni-opportunistic-security-03&difftype=--hwdiff&submit=Go!&url2=draft-dukhovni-opportunistic-security-04

The text that is in black is unchanged.  There remarkably little black text.

It's not possible for a revision to make changes that extensive and be
ready for IESG processing.

d/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Aug 2014 06:42:31 +0200

Hi,

I agree with many – not all–  of Dave's comments.  But I wanted to add
one of my own:

> How is this relevant to OS, and what is it in the definition that would

Yes, this is somewhat confusing.  I think the claim is that even if you
have an authenticated channel, that's still OS.  But authentication
usually means that there is a signal of some form to the application or
the user, and that signal can only be binary.  In order for it to be so,
you need to establish minimum safe cypher suites.  Is that were the text
was meant to go?

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Aug 2014 07:58:15 -0700

> you need to establish minimum safe cypher suites.  Is that were the text

I believe this demonstrates a very basic confusion in both the document
and with the author, about the meaning and applicability of the term.

The term is defined essentially as a style of designing flexibility into
a protocol.

As such, it is not possible for a particular security component
mechanism, like DANE or TLS to "have" or to "be" OS.

However it seems to be geting used as if it is, itself, a protocol
mechanism.

An OS approach might include one or another such component, but that's
not the same meaning at all.

At the least, this is an example of how the document needs far greater
clarity than it currently has, if it is to have substantive benefit for
future design efforts.

d/