Subject: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 15 Sep 2014 03:31:46 -0700

Kathleen Moriarty has entered the following ballot position for
draft-dukhovni-opportunistic-security-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this draft, Viktor.  I have some suggested text
to update a few sentences that I would like you to consider.

Bottom of page 2, suggested text edit to clarify meaning on the last
sentence:
Change from:
   Protection against active attacks requires authentication.  The
   ability to authenticate any potential peer on the Internet requires
   an authentication mechanism that encompasses all such peers.  No IETF
   standards for authentication meet this requirement.

To:
   Protection against active attacks requires authentication.  The
   ability to authenticate any potential peer on the Internet requires
   an authentication mechanism that encompasses all such peers.  No IETF
   standards for authentication scales as needed and have been deployed
   widely enough to meet this requirement.

on page 3, I recommend updates to the 2nd and third sentences to more
correctly describe the issue with CAs (it's not just one that we all need
to trust)
change from:
   With so many
   certification authorities, which not everyone is willing to trust,
   the communicating parties don't always agree on a mutually trusted
   CA.  Without a mutually trusted CA, authentication fails, leading to
   communications failure in protocols that mandate authentication.

To:
    With so many
    certification authorities, which not everyone is willing to trust,
    the communicating parties don't always agree on a mutually trusted
    CA from their respective lists of trusted CAs.
    Without a mutually trusted CA, authentication fails, leading to
    communications failure in protocols that mandate authentication.

For the terminology section, I do like that OS is defined in the
introduction and saw that many provided feedback asking for that to be
done.  Thanks for making the change.  Should there also be a pointer from
the terminology section back to section 1 for the definition of OS?

Security Considerations section:
I'd be happier if the first sentence had a pointer to section 3 so there
is context to the statement.

Perhaps change from:
   OS supports communication that is authenticated and encrypted,
   unauthenticated and encrypted, or cleartext. 
To:
   OS supports communication that is authenticated and encrypted,
   unauthenticated and encrypted, or cleartext (see Section 3.
Opportunistic Security Design Principles). 

Or something similar just to make the point that the purpose of OS is to
offer another option between authenticated and encrypted and cleartext as
opposed to just saying they are all supported.

Side note:  Thank you for your work on this draft and partaking in the
many discussion threads about the contents of the draft.  The discussion
on this draft were heated at times and I would have preferred to see more
detailed responses to the list on *some* of the threads, those which
offered direct suggestions.  I think that could have helped the overall
tone and interactions for a least a few of the commenters.  Some
reviewers put in considerable time helping to revise the draft, Steve
Kent in particular, and that is very much appreciated.  

I do think the draft is good enough, but I would like to see my comments
addressed to clarify a few more points.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Sep 2014 07:59:42 -0700

<shepherd hat on>

Thanks for the comments. Those all seem reasonable and within the scope of the rough consensus during IETF Last Call. Viktor will collect these and other IESG comments for a new draft to be posted after the IESG telechat.

--Paul Hoffman

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 Sep 2014 08:59:52 -0400

Hello,

I appreciate the review and acceptance of my comments, thank you.

Since posting my review on the OS draft, I have received feedback directly
from several community members who either provided text and did not get a
response (text was silently dropped) or raised a question and did not get a
response (may have been seen as "in the rough", don't know).  From the
folks that provided unsolicited feedback to me, I would like to see if we
can get some of the unanswered questioned addressed to understand the
outcome in the draft.

After additional review on specific text suggestions, I think the problem
may have been a direct result of using GitHub for editing the draft.  While
this is a good and helpful tool, it seems it may have led to a gap in
transparency as to why suggested text was accepted or dropped.  If I am
missing where to look for the answers as to why text was accepted/rejected,
please provide a pointer.  **Otherwise, if we plan to continue using such
tools (and I think the answer is yes), we'll have to find a way to make
this process more clear.**

I have a few questions broken out below from the recent feedback. I tried
to number each question to make this a bit easier to respond.

1. Text on "who is the intended audience for this draft"
Eliot Lear had concerns that a particular question Dave Crocker had raised
did not get a response.  The request was to have the draft state for which
audience the draft was intended.  There was at one point text in a Github
version of the draft that addressed this question, can you let me know why
it was dropped?  From what I can tell, it was dropped silently, so I'd just
like to understand why, it may be fine, but wanted to check as folks may
not have been aware that this text was even proposed to answer this
question.  I think this text was from Paul Wouters provided in GitHub.
 Were other opposed to including this information?  Does it need to be
tweaked?

-     This document is aimed primarily at protocol designers.  It
-     promotes designs in which cryptographic protection against
-     both passive and active attacks works without creating barriers
-     to communication and can be rolled out incrementally as suitably
-     capable systems are deployed.  This document is also aimed at
-     operators who set policy for systems that can make use of
-     opportunistic security.

2. Paul Wouters provided some feedback through the GitHub version between 3
and 4.  I went through Paul's suggested text and think the difference in
text could be answered with the question of who is the intended audience.
 Paul's text in some cases simplified the existing text and in other cases,
he provided specific examples.  I think his summary was adapted and
replaced the abstract (may be wrong on that), so it seems some was accepted.

>From my observation, many of the suggestions included examples that were
not incorporated into version -04.  Was there consensus to reduce the
number of examples?  Knowing the answer to this question, would explain why
many of his suggestions were not accepted without the need for a
point-by-point response to each proposal of that type.

3. If I am missing where to look for information on the accept/reject of
edits through the GitHub process, a pointer would be greatly appreciated.
 Here are some specific points from reviewing Paul Woulter's submission
that I'm not sure had a response, I can't generalize with the above
catch-all, or I see similar enough text capturing the same point in the
draft.  I appreciate feedback from Paul Hoffman as shepherd or Viktor as
editor for each of these points:

a. Section 2. Terminology
The last clause of the sentence was suggested and not accepted in the TOFU
definition:
        <t hangText="Trust on First Use (TOFU):">In a protocol, TOFU
-       typically consists of accepting an asserted identity, without
-       authenticating that assertion, and caching a key or credential
-       associated with the identity.

b. Section 3.
Specific suggestions were provided on this section, but it has been
completely re-worked, so the suggestions were not accepted.  This is enough
of a change that another review may have been warranted.  I do like the
version in draft-04 and think it was a positive improvement.  Can you point
me to agreement on the new text in this section as well as the discussion
on accepting rejecting text that was proposed?  I think this all boils down
to better processes when tools like GitHub are used for editing.

c. For the text in section 3 on "Maximize security peer by peer", version 3
had conditions for failure included and Paul suggested that operational
consideration should also be listed.  It looks like version 4 dropped any
mention of it failing, can you point to the decision on this particular
point as it would explain why Paul's suggested text was not accepted.
 Paul's starts with the "-"

     <t hangText="Maximize security peer by peer:"> Opportunistic
      security strives to maximize security based on the capabilities
      of the peers.  Communications traffic should generally be at
      least encrypted.  Opportunistic security protocols may refuse to
      communicate with peers for which higher security is expected,
-     but for some reason is not achieved.  The conditions under
-     which connections fail should generally be limited to operational
-     errors at one or the other peer or an active attack, so that
-     well-maintained systems rarely encounter problems in normal
-     use of opportunistic security.  </t>
+     but for some reason is not achieved. Advertised capability must match
+     reality to ensure the only condition under which there is a failure
+     of communication is when one or both peers are under an active attack.
+     </t>

d. Paul had also suggested text that looks like I addressed in one of my
comments where he suggested a "set of CAs".  I think we are good on that
one now.

e. Steve Kent's detailed review
I have not gone through this point-by-point yet, but Steve also complained
that he didn't get feedback.  It's my observation that Steve tends to give
very detailed reviews, so this one was no different from other ones (look
at the SecDir review for one of the JOSE drafts).  I do think understanding
the accept/reject process when GitHub was used would be helpful.  Can sets
of suggestions be grouped to provide an explanation of why they were
dropped?  If not, a point-by point might be helpful.

f.  Did I miss anyone that gave a detailed review and didn't get this type
of feedback?  Some was not on list unfortunately.  I may add to this list
if I find some more specific points that I am not sure were addressed.

Thanks!

On Mon, Sep 15, 2014 at 10:59 AM, Paul Hoffman <[email-masked]>
wrote:

> <shepherd hat on>
>
> Thanks for the comments. Those all seem reasonable and within the scope of
> the rough consensus during IETF Last Call. Viktor will collect these and
> other IESG comments for a new draft to be posted after the IESG telechat.
>
> --Paul Hoffman

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 16 Sep 2014 09:33:45 -0400

I should note that I believe the text provided was offlist in response to a
request from Viktor to several of the active participants to review a
version between -03 and -04.  I think this is where a bunch of the comments
were dropped without feedback as to why it was accepted/rejected.  I
*think* Steve Kent also posted his to the list, but others may not have
done the same.

On Tue, Sep 16, 2014 at 8:59 AM, Kathleen Moriarty <
[email-masked]> wrote:

> 2. Paul Wouters provided some feedback through the GitHub version between
> 3 and 4.  I went through Paul's suggested text and think the difference in
> c. For the text in section 3 on "Maximize security peer by peer", version
> 3 had conditions for failure included and Paul suggested that operational
>> Thanks for the comments. Those all seem reasonable and within the scope
>> of the rough consensus during IETF Last Call. Viktor will collect these and

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Sep 2014 14:36:41 +0100

> *think* Steve Kent also posted his to the list, but others may not have

Ah, that sounds right, was wondering a bit about some of that.
Will get back with more detail when I (or Viktor/Paul) have had
a chance to go back to the list and get the relevant URLs but
I do think all of those onlist messages did get responses that
were sufficient, if not blow-by-blow in all cases. (Which I
maintain is not always required, esp. when there's so much traffic
and/or multiple conflicting editorial suggestions being handled.)
But more anon, tomorrow probably.

Cheers,
S.

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Sep 2014 11:07:07 +0100

Hiya,

(Starting to try address IESG comments that can be covered
before the call or won't need discussion.)

Just to follow up on that, yes I think there'll be a -05
and Viktor can work with Kathleen on incorporating these
comments in that.

S.

On 15/09/14 15:59, Paul Hoffman wrote:
> <shepherd hat on>
> 
> Thanks for the comments. Those all seem reasonable and within the
> scope of the rough consensus during IETF Last Call. Viktor will
> collect these and other IESG comments for a new draft to be posted
> after the IESG telechat.
> 
> --Paul Hoffman
>