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

From: Warren Kumari <[email-masked]>
Date: Mon, 5 Mar 2018 10:58:24 -0500

On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla <[email-masked]> wrote:
>
>
> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <[email-masked]> wrote:
>>
>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>> <[email-masked]> wrote:
>> > Hi, Benoit,
>> >
>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise <[email-masked]>
>> > wrote:
>> >>
>> >> The way I see it, we're going to fix comments forever.
>> >
>> >
>> > Right. But my concern was that the text that we're reading for an
>> > up/down
>> > vote can change after we read it, so I should be tracking the proposed
>> > text
>> > changes.
>>
>> [ Updating in the middle of the thread as this seems the logical entry
>> point ]
>>
>> ... so, we are not updating the current version (we wanted 7 days for
>> people to read it), and so will be (I believe) balloting on that --
>> but, just like any other document we ballot on, the RAD will pay
>> attention to comments received and "Do the right thing".
>>
>> I believe that EKRs comments are helpful, and Kathleen hopes to
>> address / incorporate them before the call. I will be putting both the
>> current (being balloted on) and updated version in GitHub (for a
>> friendly web enabled diff) so that people can see what the final
>> version will actually look like.
>> So, I guess we are formally balloting (unless the DISCUSS is cleared)
>> on the text as written (-22), but with an understanding that the AD
>> will make it look like the version in GitHub before taking off the
>> Approved, Revised ID needed / AD follow-up flag.
>>
>> Confused yet? :-P
>
>
> Hi Warren,
>
> Thanks for this note.
>
> It's too bad that we aren't able to see the proposed revisions at this
> point, but I appreciate your commitment to working through the
> remaining issues, and I think we should be able to reach a
> satisfactory resolution.

I appreciate your Abstain, but, as mentioned, I'm committed to making
sure that the right thing happens here - a new version of the document
(-24) was posted on Friday; I believe that it is now acceptable, and
Paul (the document shepherd) also kindly looked through your comments
and the changes and thinks it's OK.

I'm sure that you are tired of this by now, but please take a look at
the diffs (stuffed in GitHub
(https://github.com/wkumari/effect-encrypt/commit/974db6cb13faecbf5b1704c1da580b320843d0b3)
or on the IETF site
(https://www.ietf.org/rfcdiff?url1=draft-mm-wg-effect-encrypt-22&url2=draft-mm-wg-effect-encrypt-24)
and let mw know if the document is something you can live with...

W

>  In the interest of not forcing everyone to
> read the document by tomorrow, I'm going to change my ballot to
> Abstain.
>
> Best,
> -Ekr
>
>
>
>
>
>
>>
>>
>>
>> >
>> > That doesn't seem up/down. It seems like every other draft I've balloted
>> > on
>> > as an AD :-)
>> >
>>
>> Indeed.
>> W
>>
>> > Spencer
>> >
>> >>
>> >> And we need to resolve this one before the current ADs step down.
>> >>
>> >> Regards, Benoit
>> >>
>> >> This may not be my week, when it comes to comprehension. At least, I'm
>> >> 0
>> >> for 2 so far today.
>> >>
>> >> Are we still tuning text in this draft?
>> >>
>> >> https://www.ietf.org/standards/process/iesg-ballots/ says that the
>> >> alternate balloting procedure is an up/down vote - we either agree to
>> >> publish, or agree to send a document off for rework.
>> >>
>> >> If we're still resolving comments, one can imagine that we'd get to a
>> >> one-Discuss situation, or even no Discusses, and wouldn't be doing an
>> >> Alternate Ballot on Thursday.
>> >>
>> >> I don't object to resolving comments (actually, I find that lovely),
>> >> but I
>> >> don't know what we're doing.
>> >>
>> >> I've never seen the alternate balloting procedure executed (either as
>> >> IESG
>> >> scribe or as an IESG member), so maybe I don't get it, and other people
>> >> have
>> >> different expectations.
>> >>
>> >> Spencer
>> >>
>> >>
>> >> _______________________________________________
>> >> OPSAWG mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/opsawg
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > OPSAWG mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/opsawg
>> >
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>    ---maf
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Mar 2018 10:07:05 -0400

EKR,
I'm planning on clicking the "This document is approved" button before
the IETF101 meeting unless I hear a clear signal that there is
something that you *cannot* live with.

Thank you again for your Abstain and all of your comments on the document,
W

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2018 07:12:02 -0700

Hi Warren,

I am on travel today, but I expect to read this today or Friday. Can you
give me until Saturday?

Thanks,
-Ekr

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Mar 2018 15:04:06 +0000

> I am on travel today, but I expect to read this today or Friday. Can you

Sure.
W

>> > (
>> https://github.com/wkumari/effect-encrypt/commit/974db6cb13faecbf5b1704c1da580b320843d0b3
>> )
>> > or on the IETF site
>> > (
>> https://www.ietf.org/rfcdiff?url1=draft-mm-wg-effect-encrypt-22&url2=draft-mm-wg-effect-encrypt-24
>> )
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Mar 2018 17:36:34 -0700

I have reviewed the new version. Thanks for incorporating my comments.

I have two substantive comment and a bunch of editorial suggestions. LMK if
you
would like me to put this in the tracker.

SUBSTANTIVE

   for attack traffic, meeting regulatory requirements, or for other
   purposes.  The implications for enterprises, who own the data on
   their networks is very different from service providers who may be

I don't believe that this is an accurate characterization of the
relationship between employees and enterprises. It may be that my
employer forbids me to access Facebook but that doesn't give them
ownership of my FB data. Perhaps "enterprises, whose networks are
often only made accessible for business purposes"

   only the headers exposed for the data-link, network, and transport
   layers.  Delving deeper into packets is possible, but there is
   typically a high degree of accuracy from the header information and

I don't believe this is accurate either. Sandvine-type DPI devices are
certainly intended for SPs.

EDITORIAL

   negotiation process resulting in fallback to the use of clear text.
   There has already been documented cases of service providers
   preventing STARTTLS to prevent session encryption negotiation on some
Nit: have already.

   session to inject a super cookie to enable tracking of users for
   advertisers, also considered an attack.  These serves as examples of
   undesirable behavior that could be prevented through upfront
Nit: serve as

   their networks is very different from service providers who may be
   accessing content that violates privacy considerations.
   Additionally, service provider equipment is designed for accessing
perhaps "in a way that violates"

   supporting protocols (e.g., DNS, DHCP), network and transport (e.g.,
   IP, TCP), and some higher layer protocols (e.g., RTP, RTCP).
   Troubleshooting will move closer to the endpoint with increased
They don't do HTTP inspection?

   A gap exists for vendors where built-in diagnostics and
   serviceability is not adequate to provide detailed logging and
   debugging capabilities that, when possible, can access cleartext
Nit: "are not"

   debugging capabilities that, when possible, can access cleartext
   network parameters.  In addition to traditional logging and debugging
   methods, packet tracing and inspection along the service path
I think you've got some sort of agreement problem here. It's not the
capabilities that can access plaintext.

   filters content based on a blacklist of sites or based on the user's
   pre-defined profile (e.g. for age sensitive content).  Although
   filtering can be done by many methods, one commonly used method
Nit: "e.g.,"

   encryption that prevents monitoring via interception, while providing
   forward secrecy.
This text is unobjectionable but perhaps not maximally clear. Perhaps:

"A number of these tools provide passive decryption by providing the
monitoring device with the server's private key. The move to increased use
of of forward-secret key exchange mechanism impacts the use of these
techniques".

   more effective at preventing malware from entering the network.  Some
   enterprises may be more aggessive in their filtering and monitoring
   policy, causing undesirable outcomes.  Web filtering solutions
Nit: aggressive.

   encrypted.  Multiplexed formats (such as HTTP/2 and QUIC) <xref
   target="QUIC"></xref> may however incorporate several application
   streams over one connection, which makes the bitrate/pacing no longer
Something went wrong with your reference here.

       user IP flows, deploying them would require enhancing them with
       tunnel translation, tunnel management functions etc..
Nit: extra period

              Society, "The Security Impact of HTTPS Interception",
              2017.
You seem to have lost the authors names here.

On Wed, Mar 14, 2018 at 8:04 AM, Warren Kumari <[email-masked]> wrote:

>>> > (https://github.com/wkumari/effect-encrypt/commit/
>>> 974db6cb13faecbf5b1704c1da580b320843d0b3)
>>> > or on the IETF site
>>> > (https://www.ietf.org/rfcdiff?url1=draft-mm-wg-effect-
>>> encrypt-22&url2=draft-mm-wg-effect-encrypt-24)
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 15 Mar 2018 14:16:14 -0400

Hi EKR,

I'll assume you're happy with the previous responses.  These are all
new comments and have been responded to and addressed.

I requested that the updated version be posted pending approval.
Responses  inline.

> often only made accessible for business purposes"

You are typically subject to monitoring of all traffic from a company
network by policy and a signed agreement at the time of employment (at
least in the US).  Many companies exclude financial site access as not
to expose PII, but not social media and sharing platforms as that's an
easy mechanism to exfiltrate data.

These sites are still accessible, just monitored, so I wouldn't want
to falsely change the text to say the network is only available for
business purposes.  I would personally advise people to follow that
practice at work though.

I made the following edits to consider the outbound access of a user
in the description of data.  The original text was focused on the
corporate data and resources.

"The implications for enterprises, who own the data on their networks
or have explicit agreements that permit monitoring of user traffic is
very different from service providers who may be accessing content
that violates privacy considerations."

> certainly intended for SPs.

The text says, "Delving deeper is possible", so that covers your
example.  The text is from Chris Morrow who has quite a bit of
operator experience into what actually happens in service provider
networks.   This text akcs that DPI is possible, but states that the
more often used information from packet streams is limited to header
information from link, network, and transport layers.  A continued
shift in this direction bodes well for end-to-end.

No change made here.

>    preventing STARTTLS to prevent session encryption negotiation on some
Changed, thanks.
>    undesirable behavior that could be prevented through upfront
Changed, thanks.
> perhaps "in a way that violates"
Changed, thanks.
> They don't do HTTP inspection?

This is again from Chris Morrow and the statement says generally
limited to supporting protocols.  That's meant to mean these are the
most common.  It doesn't exclude anything with that wording IMO.  This
does align with my experience and what we've heard.  The loudest
complaint on HTTP was redirect abilities to let customers know why
their access isn't allowed or for other notifications for non-SMS
users.

>    debugging capabilities that, when possible, can access cleartext

Changed, thanks.

> capabilities that can access plaintext.

Changed, thanks.
A gap exists for vendors where built-in diagnostics and serviceability
are not adequate to provide detailed logging and debugging
capabilities that, when possible, could be accessed with cleartext
network parameters.

>    filtering can be done by many methods, one commonly used method
Fixed, thanks.

> of of forward-secret key exchange mechanism impacts the use of these
Changed, thanks.

>    policy, causing undesirable outcomes.  Web filtering solutions

Fixed, thanks.
> Something went wrong with your reference here.
Fixed, thanks.  Editor issue and I thought I had caught all of them previously.

>        tunnel translation, tunnel management functions etc..
Fixed, thanks.

> You seem to have lost the authors names here.
Fixed, thanks.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Mar 2018 14:29:39 +0000

Thanks for your response. I am OK with your proposed changes. Warren, I
think we're done.

-Ekr

> that violates privacy considerations."

Thanks. This seems fine.

> shift in this direction bodes well for end-to-end.

OK.

> their access isn't allowed or for other notifications for non-SMS

OK.

> capabilities that, when possible, could be accessed with cleartext

Totally, I was just trying to fix the text so it was clearer.

> >>>> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <[email-masked]
> >
> >>>> >> wrote:
> >>>> >>>
> >>>> >>> >> If we're still resolving comments, one can imagine that we'd
> get
> >>>> >>> >> to a
> >>>> >>> >> scribe or as an IESG member), so maybe I don't get it, and
> other
> >>>> >>> >> people
> >>>> >>> >> have
> >>>> >>> >> different expectations.
> >>>> >>> >>
> >>>> >>> >> Spencer
> >>>> >>> >>
> >>>> >>> >>