ietf
[Top] [All Lists]

Re: Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

2014-07-08 17:51:18
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(_at_)ietf(_dot_)org 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