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.