ietf
[Top] [All Lists]

Re: [saag]: Review of: Opportunistic Security -03 preview for comment

2014-08-15 23:49:24
On Fri, Aug 15, 2014 at 09:03:09PM -0700, John Wroclawski wrote:

From my point of view, these two wordings are indistinguishable.
Setting a least common denominator and doing better whenever possible
*is* using less-stringent protection when stronger protection is
not available. I understand there?s nuance, relating to per-peer
(which I think everyone agrees with), to the multiple dimensions
of protection, and to whether ?none? is a variant of ?least? or
not. But IMO, fundamentally these two sentences say the same thing.
If the intent is that they don?t, *very* different words may be
needed.

Except that it is different.  There is no need to make a big "your
security may be degraded" fuss when doing better than expected.
However, when failing to achieve a security goal, and settling for
less, applications have tended to put up all sorts of warnings,
fussy dialogues, ...  And are often unwilling to do less that the
maximum, and simply fail.

The change of perspective is crucial to making progress.  Cleartext
is the baseline, not comprehensive protection.  You don't fall back
from comprehensive protection, when it is does not work out, ...
You do better than the baseline when that is possible, and just
works, without disrupting communication in the absence of an attack.

This is a design guide (manifesto), not not a protocol specification,
and setting things in the right perspective matters.

It is important to understand that peer capabilities you can assume
to be there are only those that are required and available to all
peers, anything else is something that requires a specific capability
advertisement.

It makes little sense to talk about fallback from authenticated
encryption, because authentication is mostly only useful when it
is enforced.  It makes more sense to talk about enforcing authentication
when the peer publishes the appropriate key material (DANE, TACK,
...).

The mandated model of security, where everybody has to implement
it or they don't play the game, makes sense in top-down environments
like the military or enterprises.  It is not a good model for the
Internet.  We've tried it for a few decades now, it has not worked
well.  It is time for a more flexible, pragmatic approach.  I expect
opportunistic security to provide more security to more peers than
the top-down models we've grown accustomed to.

The language matters, it sets the correct mental model for moving
forward.  We need to prioritize the user's needs (move the bits)
first, and layer as much security on top of that as we can, but no
more.  Yes, you can describe a fun-house mirror view of this, in
which we're falling back from comprehensive security, But that is
not a good way to think about it.  Especially when you conclude
that authentication is not opportunistic or cleartext is outside
the artificial boundary drawn around opportunistic security,
making just unauthenticated crypt be opportunistic security, and
everything else is out.

The result of that view would be everyone implementing unauthenticated
crypto, and calling it a day.  That would be a shame, because in
the long run we do want protection from active attacks, and a way
of getting that deployed, and enabled by default, and yet not
disrupting communication when not under attack.

Perhaps I should expand the example section to explain opportunistic
DANE TLS for SMTP (even if that spec is still some weeks from LC),
not just opportunistic TLS.  Then people might have a better
understanding of how opportunistic authentication works with DANE,
and should work generally.  I don't want the draft to over-emphasize
DANE, it not just about DANE, but leaving out that example may have
resulted in text that is a too abstract.

-- 
        Viktor.

<Prev in Thread] Current Thread [Next in Thread>