S Moonesamy wrote: > According to the Abstract the memo defines the term "opportunistic > security". The Introduction section provides some information about the > issues with key management. The idea is to motivate accepting unauthenticated encryption, given that key management is not solved... > If I understood correctly, opportunistic > security is about employing as much security as possible, without falling > back to unnecessarily weak options. In other words, it is about not > requiring authentication when key management is not possible. Exactly. > I would ask why not trust on first use (mentioned in Section 1). The draft neither endorses nor discourages any particular key management approach. Rather, since none are universally applicable, it is OK to do without, or with some applications or peers employ some suitable authentication scheme. So by all means TOFU when applicable to the peer and application protocol. > From Section 2: > > "An opportunistic security protocol MUST interoperably achieve at > least unauthenticated encryption between peer systems that don't explicitly > disable this capability." > > Isn't opportunistic security a design philosophy instead of a protocol? It is an umbrella term for a family of protocols that share a design philosophy. Hence *An* opportunistic security protocol, rather than *the* opportunistic security protocol (no such thing). > As a nit, the RFC 2119 boilerplate appears in Section 3. With the Terminology. In such a short document, I think it makes sense to get to the content first. > I suggest not representing opportunistic security as strong security. > The fourth paragraph in Section 2 does not say that clearly. It can be reasonably strong with some peers. I think the "no misrepresentation" clause covers this. > "Some sending MTAs employing STARTTLS have been observed to abort > TLS transmission when the receiving MTA fails authentication, only to > immediately deliver the same message over a cleartext connection." > > During an unrelated discussion John Klensin pointed out that I did not > take into account that SMTP is hop by hop. In the example quoted above > the receiving MTA might not be providing opportunistic security. There is no such thing as a receiving MTA not providing opportunistic security. It either supports STARTTLS or not. Whether security is opportunistic is up to the sending system. The receiving system might require TLS, but can't force the sender to perform meaningful authentication. Anyway, this is off-topic, the idea of not falling back to cleartext when authentication fails is clear enough I think. > "This design blunder MUST be avoided." > > I am not enthusiastic about using RFC 2119 key words to say that. I am open to downcasing to "must" if that works better. I can see the merit of this view. > I consider "clear text" as a weak option. The two sentences quoted above > differs in the interpretation of opportunistic security. I don't think there's a problem. Cleartext fallback happens when it is unavoidable. > As the intended status is Informational I am okay with publishing this > memo. Thanks. -- Viktor.