Re: draft-dukhovni-opportunistic-security-04

[Paul Wouters <[e-mail]>]

On Tue, 26 Aug 2014, Dave Crocker wrote:

> Subject: draft-dukhovni-opportunistic-security-04

ExecSum: The document sits between a "generic advise" and "specific
protocol recommendations" and accomplishes neither. The definition
is unclear and the used language makes this document hard to read,
especially for non-native English speakers.

> This is spite of the fact that /nearly every word/ of the newest draft
> is new.

While that in itself isn't a problem, as Stephen said when talking about
a two page RFC of this kind, I do find most of my textual changes that
I proposed to make the document more readab le have been rejected for
far more prosaic fluff language:

    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.

    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.

This in my opinion is not very good text at all compared to much
simplier phrasing. Especially in light on non-native English speakers.
Doubly so for being the introduction text of the document.

I'm also really unhappy about language like:

 	this risk is consistent with the expected level of protection

 	This last outcome [...]

 	if and when all but a negligible fraction [...]

 	In essence, [...]

 	This document proposes a change of perspective. [...]

 	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.

 	In this document, the word "opportunistic" carries a positive
 	connotation. [...]

 	In such a situation [...]

While "design principle" is a better choice compared to the previous
"design pattern", I still feel it is working around defining a precise
and concrete definition.

I still find the definition of OS to be unclear. It roughly means "use
existing auth/encr protocols, but try unauthenticated encryption in their
absence" but it is unclear when "other protocols" stand on their own
and when those other protocols are "part of OS". Which again comes down
to this really being opportunistic encryption, but people are afraid
of moving towards a definition defining "if other protocols offer no
authenticated encryption, try to throw in unauthenticated encryption".
Because then it becomes clear we are talking about "OE" and not "OS".
So OS keeps including and excluding the "other protocols" throughout
the document.  Example:

 	Opportunistic security protocols may hard-fail with peers for which a
 	security capability fails to function as advertised.

This clashes with the idea that OS must always soft-fail, because the
above listed "advertised capability" is really the "other protocol"
part. Eg, if DANE is used, we have an authenticated protocol, and "OS"
does not really apply at all. The "Opportunistic" part is really a MUST
for soft-fail. That is, if OS is a protocol addition or protocol feature
(or design principle) of unauthenticated encryption, it never hard-fails.
The text does state that, but doing so while squirming around the
definition.

A new section 5 was added that states:

 	OS protocols may need to employ "fallback", to work-around a failure
 	of a security mechanisms that is found in practice to encounter
 	interoperability problems.

This really sabotages the entire document. Again, because the term OS
is unclear. Should my "OS enhanced" IMAP authenticated channel stop using
encryption when there are interoperabilty problems? This documents
suggests that might be valid. If it is making a statement about the
mandatory encryption part of other protocols, it should not even make
any statement regarding applying work-arounds.

 	When protection only against passive attacks is negotiated over a
 	channel vulnerable to active downgrade attacks, and the use of
 	encryption fails, a protocol might elect non-intrusive fallback to
 	cleartext.

Apart from the hard to read sentence, "might elect" ? And seeing there
is non-intrusive fallback, is there intrusive fallback? What does this
even mean? The "design principle" is to give to user LESS toggles, but
this text just ADDS another security toggle. I thought "OS" was all
about adding security opportunisticly without needing the user or
toggles.

In my opinion, this document needs a lot of work. There needs to be
agreement on what it is trying to say, and needs better text saying
that. What this really comes down to, is that one is better of not
reading this 6 page document and telling protocol designers:

 	In absence of authenticated encryption, use un-authenticated
 	encryption with fallback to cleartext, transparent to the user.

That should be a 1 page RFC.

Paul