Hi Rene,
Just two things on this bit...
On 06/08/14 16:55, Rene Struik wrote:
(b) The verbiage in the draft should make it more clear that
opportunistic encryption will not jeopardize those entities that wish to
only set-up secure and authentic channels, by policy. Essentially, there
are three channel categories: (i) unsecured channel; (ii) channel
providing confidentiality only; (iii) channel providing confidentiality
and authenticity. While opportunistic security aims to enable a shift
from (i) to (ii), it may also cause a shift from (iii) to (ii) -- see
also the concerns I expressed July 11, 2014, 10:08am EDT [copied at end
of this email].
First, your (iii) is not a single thing, we very often see server-auth
only for https for example, which is quite different to mutually
authenticated channels, which themselves may be e.g. TLS mutual auth or
some form of TLS server-auth+channel-binding+user-password. Also SSH's
leap-of-faith/TOFU model doesn't match any your categories well I would
assert. So, we're just not on safe ground in making any inferences
about possible "shifts" from (iii) to (ii).
That said, I do get the concern so if there's text that could/should
be added saying that changing from an existing working endpoint
authenticated channel setup to an OS setup could be a disimprovement,
that could be reasonable as a security consideration.
Cheers,
S.