Hello,
At 08:09 08-07-2014, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Opportunistic Security: some protection most of the time'
<draft-dukhovni-opportunistic-security-01.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2014-08-05. Exceptionally, comments may be
According to the Abstract the memo defines the term "opportunistic
security". The Introduction section provides some information about
the issues with key management. 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. I would ask why not trust on first use
(mentioned in Section 1). The argument in the memo is that it does
not provide any authentication for the first contact. However, what
it can convey is that the "other end" I am attempting to communicate
with is not the same as the one I communicated with for the first
contact. Does that make nation-state monitoring less
easy? Yes. I'll note that the facilities which were compromised had
the ability to implement key management.
Does trust on first use maximize deployment (see Section 2)? The
short answer is yes. Does it scale? I do not think so. It can be
argued that the 99% is being protected from monitoring. It is the 1%
which might be of interest.
Is security maximized peer by peer? The short answer is yes. Does
it scale? I do not think so (see above).
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?
As a nit, the RFC 2119 boilerplate appears in Section 3.
I suggest not representing opportunistic security as strong
security. The fourth paragraph in Section 2 does not say that clearly.
"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.
"This design blunder MUST be avoided."
I am not enthusiastic about using RFC 2119 key words to say that.
From the Security Considerations section:
"Though opportunistic security potentially supports transmission in
cleartext"
There is the following in Section 1:
"Opportunistic security encourages peers to employ as much security as
possible, without falling back to unnecessarily weak options."
I consider "clear text" as a weak option. The two sentences quoted
above differs in the interpretation of opportunistic security.
As the intended status is Informational I am okay with publishing this memo.
Regards,
S. Moonesamy