Subject: [saag] Alissa Cooper's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 17 Sep 2014 11:06:33 -0700

Alissa Cooper has entered the following ballot position for
draft-dukhovni-opportunistic-security-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who worked on this document. I think it is a helpful
contribution.

On process, prior to taking a deep dive into the LC mailing list traffic
and talking with the AD, shepherd, and author, I was originally skeptical
about whether this document had achieved rough consensus and whether IETF
process had been followed effectively. After having taken those steps, I
am convinced that both are true. 

I also now understand why the term "opportunistic security" was chosen
and believe there is rough consensus in support of using that term.

However, for a document that is quite short and a concept that is fairly
straightforward, I find this document really difficult to understand in
places. I've listed the bits that are so ambiguous that I think readers
will not understand them as DISCUSS points and other comments as COMMENT
points.

DISCUSS: 

o Section 1:
"For a particular protocol or application, if and when all but a
   negligible fraction of peers support encryption, the baseline
   security may be raised from cleartext to always require encryption.
   Similarly, once support for authentication is near-universal, the
   baseline may be raised to always require authentication."

I agree with Adrian that it is unclear what this means. And in fact it
seems to contradict other language in the document by assuming that a
protocol has one mode of operation for *all* peers. I thought one of the
goals of OS was that within any single protocol interaction or within any
single group of peers, the level of encryption used could be negotiated
up to the lowest common denominator among the peers. Perhaps this would
be clearer if it emphasized that the default mode for a particular
protocol or application might be chosen to be cleartext, unauthenticated
encryption, or authenticated encryption, with the ability for peers to
negotiate up if they are capable.

o Section 1:
"In essence, OS is employed when one might otherwise settle for
cleartext
   (or the minimum protection possible if the protocol is always
   encrypted)." 

I don't understand the parenthetical, either in substance or grammar.

o Section 1:
"For example, a policy might require authenticated, encrypted
   communication, in contrast to the default OS security policy."

This sentence presents another reason why the previous paragraph does not
make sense. The previous paragraph seems to say that in some cases, the
default OS security policy could be to use authenticated encryption. In
those cases, this sentence is not correct.

o Section 1.2:
I find the document's guidance about the extent to which OS protocols
"work behind the scenes" to be confusing. There is this text in this
section:

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

And then in Section 3 there is this:

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

The bit about working "behind the scenes" and not prompting the user
seems to me to be distinct from the issue of misrepresenting security.
That is, (1) whether the user is proactively informed of the extent to
which his communications are protected, (2) whether the user is able to
find out about that protection on his own, and (3) whether the
information provided to the user about that protection is accurate are
three separate questions. I find that Section 1.2 argues against (1),
although this is not elevated to the level of a "design principle" as it
is not included in Section 3. Section 3 argues in favor of (3) --
providing accurate information -- and includes that as a design
principle. I believe the document is silent about (2).

I get the sense that (1) is viewed by people who worked on this document
as an important by-product of wider deployment of OS, so I would have
expected support for it to be more explicit in the document, rather than
somewhat latent as it is. If there were a fuller discussion of (1), I
would also expect (2) to be addressed, as it is natural to ask just how
"behind the scenes" OS protocols are expected to be (as Adrian pointed
out). This seems like a fairly significant gap in the document.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

o Section 1:
 s/For authentication based on peer capabilities to protect
   against MiTM attacks/For authentication based on peer capabilities to
be able to protect against MiTM attacks/

(FWIW, the above makes more sense to me than Adrian's suggested edit to
the same sentence.)

o Section 1.1:
General comment: It is really unclear what the point of this section is
and why this set of paragraphs is strung together as one section. I would
suggest adding an opening paragraph along the lines of "This section
provides some background about historic and current challenges associated
with the use of encryption on the Internet, illustrated using discussion
of the Web PKI."

o Section 1.1:
s/With so many certification authorities, which not everyone is willing
to trust,
   the communicating parties don't always agree on a mutually trusted
   CA./With so many certification authorities, all of which are not
trusted by all entities, the communicating parties don't always agree on
a mutually trusted
   CA./

o Section 1.1:
"In interactive
   applications, security warnings are all too frequent, and end-users
   learn to actively ignore security problems"

This point is orthogonal to the rest of the paragraph to which it is
attached. The fact that choices were made to pop security warnings was
separate from other choices made about the web PKI. It doesn't quite make
sense to me why this is mushed together with a paragraph about "cost and
management burdens."

o Section 1.1:
"For encryption to be used more broadly, authentication needs to be
   optional.  The use of encryption defends against pervasive monitoring
   and other passive attacks (which are employed not only by nation
   states).  Even unauthenticated, encrypted communication (defined
   below) is preferable to cleartext."

This seems like it should be the first paragraph of Section 1.2. It is
rather out of place in Section 1.2.

o Section 3:
"OS offers an incremental path to authenticated, encrypted communication
in the
   future, as suitable authentication technologies are deployed."

As in Section 1, this text seems to assume one mode of operation for a
particular protocol. What about protocols that can already support
authenticated encryption? Doesn't OS offer an incremental path towards
using that mode right now, not in the future, for peers that already
support it?

o Section 3:
s/Communication should generally
      be at least encrypted./At a minimum, communication should
generally
      be encrypted without authentication./

(I think this was the intention here, although I'm not completely sure
what "at least" means.)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Sep 2014 20:32:16 +0100

Thanks Alissa,

Back to you on those tomorrow. Nothing there seems mad
to me anyway:-)

S

On 17/09/14 19:06, Alissa Cooper wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 18 Sep 2014 16:13:25 +0000

> negotiate up if they are capable.

The language is about protocol designs, and the specified baseline
for a given protocol.

The intent is to allow future revisions of say SMTP to specify
unauthenticated TLS as a baseline requirement (obviously subject
to local policy that might relax to cleartext in some deployments
or with some peers).  Naturally, such decisions may also be made
by operators.

If this is done in the context of near universal adoption of
STARTTLS, then the default behaviour of updated or suitably configured
SMTP clients will be to require STARTTLS.  Their opportunistic
behaviour then boils down to using or not using DANE TLS authentication
based on the peer's TLSA RRs or their absence.

I don't see the contradiction part.  This language allows a (future)
lowest common denominator other than cleartext for protocols that
have achieved spectacular adoption of encryption, and are ready to
declare victory on that.

>    cleartext (or the minimum protection possible if the protocol
>    is always encrypted)."
> 

The parenthetical is therefore for hypothetical future cases in
which the baseline has been raised.

> those cases, this sentence is not correct.

I see no conflict here, the sentence gives an example in which
local policy might be different from the default OS policy, hence
presumptively when the default policy is in fact different from
authenticated, encrypted communication.

> "work behind the scenes" to be confusing. There is this text in this

OS is supposed to something non-intrusive that is on by default,
and needs to rarely fail in practice (absent an actual attack).

> seems to me to be distinct from the issue of misrepresenting security.

They are, as you observe, in fact different.  One is about not
being fragile or intrusive, the other is about not over-representing
the security achieved, if any.

In the former we're discouraging failure modes and warning dialogs,
in the latter we're discouraging misleading security indicators.

> That is, (1) whether the user is pro-actively informed of the extent to

The draft argues against misrepresentation, this is not the same
as suppression of information.  So there is no argument against
(1) in 1.2 or in 3.

> principle. I believe the document is silent about (2).

Indeed the document is strategically silent about user interfaces.

> somewhat latent as it is.

I think of it in the converse.  Non-intrusive designs make wider
deployment more likely, by not getting in the way of communication.
The corollary is that OS designs should be non-intrusive, especially
because they're typically intended to be transparent upgrades from
no security.

> If there were a fuller discussion of (1), I

Many comments wanted a shorter document.  I am willing to write
more, but tried to strike a balance between outlining the principles
as briefly as possible and detailed exposition.

> (FWIW, the above makes more sense to me than Adrian's suggested edit to

Yes, this matches the intent and I think addresses Adrian's concerns
with the same text.

> with the use of encryption on the Internet, illustrated using discussion

This section explains why we don't yet have ubiquitous authenticated
encryption, and why therefore authentication needs to be optional.
An opening sentence or paragraph can be added to say so.

>   to trust, the communicating parties don't always agree on a mutually
>   trusted CA./With so many certification authorities, all of which are
>   not trusted by all entities, the communicating parties don't always
>   agree on a mutually trusted CA./

The suggested text is not IMHO better, but we can try to make the
original more clear.  (To me "all of which are not trusted by all"
means none are trusted by any).

>    learn to actively ignore security problems"

This is text from Paul Wouters, ... I think it is a fair point.
When security expectations exceed reality, one gets various kinds
of friction.

> sense to me why this is mushed together with a paragraph about "cost and

One of the costs is habituating users to work-around security.
However, this point is not essential and could be merged into
Security Considerations or dropped if that's better..

> rather out of place in Section 1.1.

This is the conclusion of 1.1, based on the evidence presented
above it, since 1.1 argues for optional authentication.

>    in the future, as suitable authentication technologies are deployed."
> 

The text is intended to be read under the assumption that the
protocol is substantially using cleartext today, OS enables unauth
encryption now, and can enable authentication in the future.  That
is, the discussion is about opportunistic authentication, not
mandatory authentication via local policy.

There is very little present deployment of OS with authentication,
for lack of downgrade resistant out-of-band signalling.  Just a
few medium size providers in Germany and some small enthusiast
domains.

This text can be made more clear.

>       generally be encrypted without authentication./
>

The interpretation is correct.  A clearer update is possible.

-- 
	Viktor.