ietf
[Top] [All Lists]

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

2014-08-06 10:42:39
Viktor,

Rather than deal with each of your responses to my comments individually,
I'll just provide some overall responses.

1. My comments on the abstract are not about blame, but about clarity in
writing. It is important to distinguish between standards and what is deployed,
especially because we can control only the former.

2. I have seen considerable feedback from various sources, including the GEN-ART
review, that does not suggest that the doc is fine "as-is."

3. I've rarely seen someone suggest that being more precise in terminology
is a bad thing. I think we owe it to readers of RFCs to be a clear as possible.
Clarity in writing, and concision, yield good docs. You seem to believe that
making a doc more precise makes it verbose. That is not a necessary outcome.

4. The term "collection" is generally defined as passive wiretapping, so encryption
suffices, irrespective of using other security services.

5. Yes, you are not alone in making an erroneous statement that conflates
PKIX standards and the Web PKI. However, that does not justify perpetuating
such errors in an RFC.

6. The definition of OS appears at the end of Section 3, after all of the background. My comments argued that it appear sooner, which is not the same as saying that it needs
appear in the Intro, contrary to your complaints.

7. I called into question the phrase "reasonably configured peer." Your reply was
wordy and missed the point of my criticism.

8. You seem to have misunderstood why I found the term "many" to be confusing; changing it to "non-negligible number" misses the point. The point is that the text is clearer is one discusses a pair of peers trying to communicate. Also, I note that another person cited the
same problem; it's not just me!

9. The phrase "security settings" is vague, since it means different things in different security protocol contexts. You later seem to acknowledge this when you observe that TLS and SMTP security settings are different. Saying that OS can be deployed "organically"
suggests spreading around a lot of manure :-).

10. yes, do drop the term "application" when there is no intent to restrict solutions to
be app-specific.

11. Your effort to clarify what you mean by "misconfigured" was a revelation to me.
I did not get any sense of that meaning from the text.

12. Saying that an OS-capable peer may demand more than unauthenticated encryption does conflict with the stated goal of not requiring coordination (between administrators). I think
this is an example of trying to make the term OS all encompassing.

13. Your attempts to reconcile what you refer to as "no ceiling" for OS and the simple notion of unauthenticated encryption between OS-capable peers yields text that is confusing, borderline contradictory. I noted several examples. Your replies either insist there is no problem (and that the meaning is clear) or offer additional
text that is marginally better.

14. I said that the suggestion to use PFS was out of place in the goal where it
appeared. Your reply missed the point entirely.

15. I observed that the closing MTA example is inappropriate in a doc of this sort. I should also have noted that the use of MUST here makes no sense in an informational RFC defining terminology. Your reply suggests that you again missed the point.


<Prev in Thread] Current Thread [Next in Thread>