Re: Gen-ART review of draft-dukhovni-opportunistic-security-01

[Viktor Dukhovni <[e-mail]>]

On Thu, Jul 10, 2014 at 05:16:15PM -0700, Martin Thomson wrote:

> Major issues:
> 
> 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.

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

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

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

Opportunistic security is NOT a synonym for unauthenticated
encryption.

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

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

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

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

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

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

-- 
	Viktor.