[OPSAWG] New Version Notification - draft-mm-wg-effect-encrypt-22.txt

[internet-drafts]

A new version (-22) has been submitted for draft-mm-wg-effect-encrypt:
https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-22.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-22

Please note that it may take a couple of minutes from the time of submission
until the diff is available at tools.ietf.org.

IETF Secretariat.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Alissa Cooper's Abstain on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Kathleen Moriarty]

Hi Alissa,

I believe this is the last set of comments received that we had left
to respond.  The next update that will come out shortly following this
message should address all comments and subsequent discussions
received to date.

On Thu, Feb 8, 2018 at 8:26 AM, Alissa Cooper  wrote:
> Alissa Cooper has entered the following ballot position for
> draft-mm-wg-effect-encrypt-17: Abstain
>
> 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 https://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:
> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/
>
>
>
> --
> COMMENT:
> --
>
> Many thanks for all the effort that has gone in to addressing all the comments
> from the last IESG review and from the community. I find this version to be
> much improved from the last time the IESG reviewed it.
>
> However, I do not feel that I can support the publication of the document.
> While the tone has improved in many places and the introduction does a better
> job of contextualizing the document, the document still contains text in
> several sections that states service providers' claims about their practices 
> as
> facts rather than stating them as claims or presenting the practices in a
> neutral way. This was a point raised in my previous DISCUSS (I've included my
> previous DISCUSS ballot text below in full for reference). In the previous
> review round Warren had invited recommendations for places where the tone or
> choice of words could be made more neutral or balanced, and I provided many
> detailed suggestions, but a number of those were not adopted. I also realize
> that the introduction contains much of the disclaimer text we previously 
> hashed
> out to try to address this, but it doesn't contain all of it. So this is still
> a major issue for the document, IMO.

I believe we had responded to the discussion and left off with the
updates matching the last parts of the discussion.

>
> The document also still extemporizes about future possible impacts, making it
> hard to come away with a neutral view of their treatment, as I noted in my
> previous DISCUSS ballot.
>
> I support the DISCUSS position held by Ekr. But given the above I don't think
> it will be fruitful for me to continue to engage on the details of this
> document, so I'm abstaining.
>
> I've included below some of the areas that I still find problematic, as well 
> as
> some nits.
>
> Problematic areas:
>
> = Section 2.1.2 =
>
> (1)
> "Network operators are often the first ones called upon to investigate
>application problems"
>
> I still contend that without data to back this up, this claim should not be
> made, especially for the enterprise context.

This is in section 2.1.2, which is specific to service provider
networks.  Al responded on this previously from his experience.  My
experience having worked at a service provider and having managed/been
responsible for the security of several large enterprises matches his
- the service provider is often the first call, especially with the
cited example.  If there's a perceived issue that's network related,
you have an SLA with the service provider and they have to assist.
They will figure out if there is a routing issue, congestion, the
service is not responding, DDoS, or something else that is happening
to cause the trouble.  These are all issues that require a little
network troubleshooting before you point the problem at the
application.  It's not as easy with an application as you don't always
have someone you can call.  The service provider may be seeing the
application issue from multiple customers and may then act on behalf
of many customers to get in touch with the application provider.
Getting to the right person at an application provider is typically
much harder then the initial troubleshooting steps to discover if
there is a network issue.  I'd be embarrassed if I called an
application provider and the issue was the network.  I'd want to rule
out the network and services like DNS prior to making that call.

I know this is one Al wanted to hold firm on and I agree with him from
my experience.

How about the following to make the point more clear for those not
familiar with troubleshooting:

OLD:
Network operators are often the first ones called upon to investigate
application problems (e.g., "my HD video is choppy").

NEW:
Network operators are often the first ones called upon to investigate
application problems (e.g., "my HD video is choppy"), to first rule
out network and network services as a cause for the underlying issue.

I 

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Kathleen Moriarty]

Hi Eric,

A quick update per the discussion on a TLS draft.

On Mon, Feb 19, 2018 at 3:11 PM, Kathleen Moriarty
 wrote:
> Hi Eric,
>
> Thanks for your feedback, responses are inline.
>
> FYI - I posted another version, but expect at least one more iteration
> after this version with additional comments and the ones we haven't
> gotten to yet.
>
> On Thu, Feb 8, 2018 at 12:04 AM, Eric Rescorla  wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-mm-wg-effect-encrypt-17: Discuss
>>
>> 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 https://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:
>> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> I have completely re-reviewed the latest version. First, I want to
>> thank you for toning down some of the material that I was concerned
>> about.
>>
>> Unfortunately, the fundamental concern that motivated my DISCUSS
>> remains: I do not believe that this document matches the consensus
>> of the IETF community.
>>
>> Specifically, this document takes at face value a large number of
>> claims about the necessity/value of certain practices that either are
>> controversial within the IETF or that there is, I believe, rough
>> consensus to be actively bad, and that in many cases, encryption is
>> specifically designed to prevent. I have noted a number of these
>> below, but I do not believe that this is an exhaustive list (going
>> through my previous DISCUSS, I see that I noted a number of these but
>> that still appear to be unaddressed.)
>
> In the previous round of IESG reviews, the IESG concluded that framing
> upfront was the preferred approach to make it clear that not all cited
> practices are ones the IETF consider valid.  This was done in the
> updated introduction.
>
> Please respond to the discussion points as I believe your additional
> points have been addressed to also make these points again in the
> document.  In a couple of places, we have questions to make sure your
> concern is understood.
>
>>
>>
>> DISCUSS
>>session encryption that deployed more easily instead of no
>>encryption.
>>
>> I think I understand what you are saying here, but the term
>> "breakable" seems very unfortunate, especially in the context of this
>> document. The only such shift I am aware of that has received
>> acceptance in IETF is one from always requiring fully authenticated
>> encryption to allowing unauthenticated encryption, which you document
>> in the next paragraph. I recognize that there are other perspectives
>> (e.g., those in draft-rhrd) but those are pretty far from IETF
>> consenus. Accordingly, I think you should remove this sentence.
>
> Opportunistic security was well discussed, so that was likely top of
> mind for you when reading this draft. However there are other areas
> where the IETF decided breakable encryption was better than none in
> recent years.  Another adopted and published example is in the mail
> community.  Deprecating MD5 was deemed to be too hard because of
> support in a particular library.  We had lengthy discussions about
> this for RFC7627 (see sect 6.2) and related drafts, now published
> RFCs.
>
> This sentence had nothing to do with the drafts that are not WG drafts
> in the TLS WG, but real use cases of published RFCs where deprecated
> crypto is still accepted despite efforts to correct that in addition
> to the acceptance of the OS approach in multiple session encryption
> protocols.  The support tools and use cases don't always drive the
> best solution where we have strong crypto everywhere as you have also
> noted on recent draft reviews, now published RFCs.
>
>>
>>
>>motivation outside of privacy and pervasive monitoring that are
>>driving end-to-end encryption for these content providers.
>>
>> This section seems kind of confusing, at least as applied to
>> HTTP. There are three kinds of cache in HTTP:
>>
>> - Reverse proxy caches (the kind CDNs run)
>> - Explicit forward proxy caches
>> - "Transparent" intercepting caches
>>
>> The first of these move to HTTPS just fine and that's typically how
>> CDNs do it.  Explicit forward proxy caches are largely going away, but
>> part of the point of this kind of end-to-end encryption is to hide
>> data from those caches.
>
> Sure, that point was made in the draft and cleared up a little further
> from Benjamin K's review.  The business risk associated with not
> controlling your content was more explicitly stated for 

[OPSAWG] Publication has been requested for draft-ietf-opsawg-mud-17

[Joe Clarke]

Joe Clarke has requested publication of draft-ietf-opsawg-mud-17 as Proposed 
Standard on behalf of the OPSAWG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Opsdir early review of draft-ietf-opsawg-nat-yang-10

[Benoit Claise]

Hi Tim,

I raised the question in my ops-dir review on whether it was OK for a Standards 
Track document (draft-ietf-opsawg-nat-yang) to include definitions for an 
Experimental Track mechanism (NPT66).

I don't personally have a strong view either way, but felt obliged to point out 
the discrepancy

And you can be sure that this is much appreciated. Thanks for your feedback.

Regards, Benoit

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Opsdir early review of draft-ietf-opsawg-nat-yang-10

[Tim Chown]

> On 21 Feb 2018, at 21:03, Warren Kumari  wrote:
> 
> On Wed, Feb 21, 2018 at 12:27 PM, Benoit Claise  wrote:
>> Dear all,
>> 
>> I'm not the responsible AD for draft-ietf-opsawg-nat-yang but let me share
>> my view from a YANG point of view.
>> Do we really believe that the intended status of Standards Track of
>> Experimental will influence whether a YANG module is implemented? This
>> module will be implemented if it solves a business issue, full stop. The
>> indented status is not even relayed into YANG module. I mean: once extracted
>> from the RFC, the YANG module is not flagged as experimental because the
>> feature to be managed is experimental.
>> 
>> From the 2 foot view, going through the extra hurdle of splitting the
>> document because one of the managed features is experimental seems to me
>> like a distraction to me.
> 
> I fully agree with Benoit. While I'm technically the responsible AD,
> Benoit is the SME (and also happens to be right :-))

I raised the question in my ops-dir review on whether it was OK for a Standards 
Track document (draft-ietf-opsawg-nat-yang) to include definitions for an 
Experimental Track mechanism (NPT66).

I don't personally have a strong view either way, but felt obliged to point out 
the discrepancy so we could get 'higher' advice on whether that was OK.  It 
seems we now have that :)

Tim

> 
> 
>> 
>> My two cents.
>> 
>> Now, if you really want to split the doc., please publish both at the same
>> time.
>> 
>> Regards, Benoit
>>> 
>>> On 2/7/18 03:14, mohamed.boucad...@orange.com wrote:
 
 Hi Joe, all,
 
 Thanks. Lets' then go that path.
 
 A new version which addresses the comments from Tim (remove the NPTv6
 part + some minor edits) is available at:
 
 https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/?include_text=1
 
 Tim, thank you for identifying this issue at this stage of the
 publication process.
 
 One logistic question for the NPTv6 document, though: Should it be
 published (1) as draft-ietf-ospawg-* given that its content was part of the
 document that was accepted by the WG and that passed the WGLC or (2) as an
 individual document that will be handed to the AD together with
 draft-ietf-opsawg-nat-yang?
>>> 
>>> My preference would be a WG document for the reasons you state, but let
>>> me check with Warren and Ignas.
>>> 
>>> Joe
>>> 
 Cheers,
 Med
 
> -Message d'origine-
> De : Joe Clarke [mailto:jcla...@cisco.com]
> Envoyé : mardi 6 février 2018 17:59
> À : BOUCADAIR Mohamed IMT/OLN; Tim Chown
> Cc : ops-...@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org;
> opsawg@ietf.org
> Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10
> 
> On 2/6/18 05:48, mohamed.boucad...@orange.com wrote:
>> 
>> Re-,
>> 
>> Either ways are easy to handle. I do a have a preference (dedicated
> 
> informative section).
>> 
>> I will wait for instructions from the chairs about how to proceed.
> 
> I do not have a strong preference, but I do think there will be
> additional augmentations the NAT module, and so I lean more towards
> another document as not to conflate the work.
> 
> Joe
> 
>> Thank you.
>> 
>> Cheers,
>> Med
>> 
>>> -Message d'origine-
>>> De : Tim Chown [mailto:tim.ch...@jisc.ac.uk]
>>> Envoyé : mardi 6 février 2018 11:17
>>> À : BOUCADAIR Mohamed IMT/OLN
>>> Cc : ops-...@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org;
>>> opsawg@ietf.org
>>> Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10
>>> 
>>> Hi,
>>> 
 On 6 Feb 2018, at 10:13, mohamed.boucad...@orange.com wrote:
 
 Re-,
 
 Please see inline.
 
 Cheers,
 Med
 
> -Message d'origine-
> De : Tim Chown [mailto:tim.ch...@jisc.ac.uk]
> Envoyé : mardi 6 février 2018 10:38
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : ops-...@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org;
> opsawg@ietf.org
> Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10
> 
> Hi Med,
> 
>> On 6 Feb 2018, at 09:02, mohamed.boucad...@orange.com wrote:
>> 
>> Hi Tim,
>> 
>> Thank you for the review.
>> 
>> Please see inline.
>> 
>> Cheers,
>> Med
>> 
>>> -Message d'origine-
>>> De : Tim Chown [mailto:tim.ch...@jisc.ac.uk]
>>> Envoyé : lundi 5 février 2018 20:07
>>> À : ops-...@ietf.org
>>> Cc : draft-ietf-opsawg-nat-yang@ietf.org; opsawg@ietf.org
>>> Objet : Opsdir early review of draft-ietf-opsawg-nat-yang-10
>>> 
>>> Reviewer: Tim Chown
>>> Review result: Has