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

[Eric Rescorla]

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)  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  wrote:

>
> On Wed, Mar 14, 2018 at 10:12 AM Eric Rescorla  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  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 
>>> wrote:
>>> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla  wrote:
>>> >>
>>> >>
>>> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari 
>>> wrote:
>>> >>>
>>> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>>> >>>  wrote:
>>> >>> > Hi, Benoit,
>>> >>> >
>>> >>> > On Mon, Feb 26, 2018 

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

[Warren Kumari]

On Wed, Mar 14, 2018 at 10:12 AM Eric Rescorla  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  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  wrote:
>> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla  wrote:
>> >>
>> >>
>> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari 
>> wrote:
>> >>>
>> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>> >>>  wrote:
>> >>> > Hi, Benoit,
>> >>> >
>> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
>> >>> > 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=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 

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

[Eric Rescorla]

Hi Warren,

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

Thanks,
-Ekr


On Wed, Mar 14, 2018 at 7:07 AM, Warren Kumari  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  wrote:
> > On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla  wrote:
> >>
> >>
> >> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari 
> wrote:
> >>>
> >>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
> >>>  wrote:
> >>> > Hi, Benoit,
> >>> >
> >>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
> >>> > 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/974db6cb13
> faecbf5b1704c1da580b320843d0b3)
> > or on the IETF site
> > (https://www.ietf.org/rfcdiff?url1=draft-mm-wg-effect-encryp
> t-22=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
> >>> >> OPSAWG@ietf.org

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

[Warren Kumari]

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  wrote:
> On Wed, Feb 28, 2018 at 9:45 AM, Eric Rescorla  wrote:
>>
>>
>> On Tue, Feb 27, 2018 at 11:23 AM, Warren Kumari  wrote:
>>>
>>> On Mon, Feb 26, 2018 at 3:28 PM, Spencer Dawkins at IETF
>>>  wrote:
>>> > Hi, Benoit,
>>> >
>>> > On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise 
>>> > 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=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
>>> >> OPSAWG@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/opsawg
>>> >>
>>> >>
>>> >
>>> >
>>> > ___
>>> > OPSAWG mailing list
>>> > OPSAWG@ietf.org
>>> > 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