Subject: [saag] Gen-ART review of draft-dukhovni-opportunistic-security-01

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Jul 2014 17:16:15 -0700

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-dukhovni-opportunistic-security-01
Reviewer: Martin Thomson
Review Date: 2014-07-08
IETF LC End Date: 2014-08-05
IESG Telechat date: (if known)

Summary: This reads a little like it was rushed.  This needs some work
before it can be considered ready.

(I've cc'd saag here.  That seemed appropriate, strip as you see fit.)

Major issues:

This misses one of the key principles behind opportunistic security:

  Insistence on failure, as opposed to downgrade or some lesser level
of security - a characteristic of non-opportunistic security - elicits
responses from users to work around the problem (accept the bad
certificate, suppress certificate checking, etc...).  The willingness
of an opportunistic security implementation to accept unvalidated
credentials means that it still benefits from resilience against
passive attack.  This is only really noted through an example of a
"design blunder".

In general, a more careful consideration of the document structure is needed.

The document skirts around it's key goal: defining OS.  Section 2
needs to start with a definition. The paragraph that follows the list
in S2 is a reasonable attempt at that and could be tweaked fairly
perform that function.

The Security Considerations is a response to an unstated argument, but
I think that the document needs to be clearer about what that argument
is, i.e.:

  The willingness of an OS implementation to downgrade can be
trivially exploited by an active attacker to strip an opportunistic
mechanisms.

The point that is made here is one that is most applicable in the
aggregate, something that is implied by "users" (in the plural form),
but should be explicit.

Minor issues:

Section 3 is unnecessary in its entirely:

  1. 2119 language isn't really appropriate for this document.  Many
of the statements that rely on this would be much better without that
language.  Some of the uses are actually completely inappropriate:
"When possible, opportunistic security SHOULD provide stronger
security on a peer-by-peer basis."

  2. I think that the description of "unauthenticated encryption" and
"TOFU" belong in the text proper.  TOFU is covered well enough by the
text in S1; unauthenticated encryption needs to be covered in the
description as a first class section, rather than piecemeal (see
above).  MitM and PFS are defined in RFC4949.

Nits/editorial comments:

References are double-bracketed "([ref])" and the "pervasive
monitoring (PM[RFC7258])" reference doesn't need the "PM".

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Jul 2014 02:41:06 +0000

> This misses one of the key principles behind opportunistic security:

Strongly disagree.  Opportunistic security does not always downgrade
to unauthenticated or unencrypted communication.  For example, with
opportunistic use of DANE TLS, authentication is enforced for peers
with usable TLSA records, while communication with other peers is
unauthenticated or perhaps even unencrypted.

So in fact, this draft specifically, and deliberately leaves the
door open for MiTM-resistant authentication of peers for which some
suitable mechanism (DANE, TOFU, ...) makes authentication possible.

> certificate, suppress certificate checking, etc...).

For MTA-to-MTA SMTP there is no user to click OK.  Not all applications
are web browsers.

> The willingness

Opportunistic security is NOT a synonym for unauthenticated
encryption.

> in S2 is a reasonable attempt at that and could be tweaked fairly

The definition is a summary of the design principles.  We're defining
an umbrella term for a family of protocols sharing a design
philosophy.  It is helpful to set out the design principles first, and
then state that OS protocols are those that adhere the design principles,
and amplify the key points.

> trivially exploited by an active attacker to strip an opportunistic

The Security Considerations section says that some protection is
strictly better than no protection.  Thus it is often OK to accept
some protection, even if some risks are left unmitigated.

> Section 3 is unnecessary in its entirety:

No terminology section required?  It is a subset of the Terminology
from Steve Kent's draft.  If it is felt that all the requisite terms
are adequately defined in-line, I am not opposed to its removal, for
this draft less bloat is better.  It should be a succint definition.

> security on a peer-by-peer basis."

I can downcase the "SHOULD", what is the objection to 2119?

> above).  MitM and PFS are defined in RFC4949.

Anyone care to suggest new language?  Is there agreement that the
proposed changes are needed?

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Jul 2014 21:12:03 -0700

(Please keep the To/Cc; the responsible ADs/shepherds probably need to
see these emails. Add ietf@ if you feel you want the larger audience;
I figured saag was a large enough peanut gallery :)

> suitable mechanism (DANE, TOFU, ...) makes authentication possible.

Maybe I chose my words poorly, but I stand by the fact that this is an
important consideration in some designs.  More important than this
document implies.

> Opportunistic security is NOT a synonym for unauthenticated

I didn't suggest that it was, but it's an important feature of the
potential design space.  The document doesn't really describe any
other features that are this prominent.

> and amplify the key points.

I stand by my comment, I think that with a title and subject matter as
is, you need to at least attempt to define the subject before
attempting to describe secondary things like design principles.

> some protection, even if some risks are left unmitigated.

Yes, but as I said, that statement is an answer to a question that is
only implied.  I think that the document would be better if it owned
up to the potential here.

> I can downcase the "SHOULD", what is the objection to 2119?

That's not my point.  The point is that you aren't making normative
statements in this document, and nor should you.  2119 language isn't
needed.

For this specific sentence, you could use lowercase "should" and still
basically have an unsupportable statement.  stronger than what?  is
this a prediction?  I'm not sure what the right language is here, but
this reads much like the argument from the security considerations,
which is - to my mind - far more precise.

> proposed changes are needed?

I'm thinking that Section 3 could be deleted and the paragraph on
unauthenticated encryption beefed up a little to note its key
characteristics and significance (deployability, failure in the face
of active attack, that it isn't the only or even necessary piece of
opportunistic encryption, etc...).