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

[Kathleen Moriarty <[e-mail]>]

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.

On Wed, Mar 14, 2018 at 8:36 PM, Eric Rescorla <[e-mail]> wrote:
> 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"

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."

>
>    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.

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.


>
>
> 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.
>
Changed, thanks.
>
>
>    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
>
Changed, thanks.
>
>
>
>    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"
>
Changed, thanks.
>
>
>
>
>    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?
>

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.

>
>
>    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"
>

Changed, thanks.

>
>
>    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.
>

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.

>
>
>    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.,"
>
Fixed, thanks.

>
>
>    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".
>
Changed, thanks.

>
>
>    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.

Fixed, thanks.
>
>
>
>    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.
>
>
Fixed, thanks.  Editor issue and I thought I had caught all of them previously.

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

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


Best regards,
Kathleen

>
> On Wed, Mar 14, 2018 at 8:04 AM, Warren Kumari <[e-mail]> wrote:
>>
>>
>> On Wed, Mar 14, 2018 at 10:12 AM Eric Rescorla <[e-mail]> wrote:
>>>
>>> Hi Warren,
>>>
>>> I am on travel today, but I expect to read this today or Friday. Can you
>>> give me until Saturday?
>>
>>
>> Sure.
>> W
>>
>>>
>>> Thanks,
>>> -Ekr
>>>
>>>
>>> On Wed, Mar 14, 2018 at 7:07 AM, Warren Kumari <[e-mail]> wrote:
>>>>
>>>> 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
>>>>
>>>> On Mon, Mar 5, 2018 at 10:58 AM, Warren Kumari <[e-mail]>
>>>> wrote:
>>>> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla <[e-mail]> wrote:
>>>> >>
>>>> >>
>>>> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari <[e-mail]>
>>>> >> wrote:
>>>> >>>
>>>> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>>>> >>> <[e-mail]> wrote:
>>>> >>> > Hi, Benoit,
>>>> >>> >
>>>> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise <[e-mail]>
>>>> >>> > 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
>>>> >>> >> [e-mail]
>>>> >>> >> https://www.ietf.org/mailman/listinfo/opsawg
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>> >
>>>> >>> > _______________________________________________
>>>> >>> > OPSAWG mailing list
>>>> >>> > [e-mail]
>>>> >>> > 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>
>



-- 

Best regards,
Kathleen