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.