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

[Eric Rescorla]

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

-Ekr

On Thu, Mar 15, 2018 at 6:16 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

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

Thanks. This seems fine.


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

OK.

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

OK.


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

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

[Kathleen Moriarty]

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

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 

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

[Warren Kumari]

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

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

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

[Kathleen Moriarty]

Thanks for your responses.  Inline responses to EKRs responses.  I
think there were some additional recent on list comments that still
need to be addressed and any adjustments from this discussion.  I just
posted to the datatracker as it didn't seem like we needed to use
github now that there isn't an alternate ballot procedure.

On Mon, Feb 26, 2018 at 1:22 PM, Eric Rescorla  wrote:
> Thanks for the updated draft. Some responses below.
>
>
> On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty
>  wrote:
>>
>>
>> >
>> > 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.
>
>
> I continue to think that the term "breakable" is very unfortunate here
> (and of course, MD5 isn't breakable "encryption").

Sure, but OS is breakable, and both are not the most secure options
available today (known weaknesses).  This is a big shift in thinking.
Even for ACME, when similar ideas were previously presented, they were
not acceptable because of the industry/IETF desire to preserve
security and ideas of what is acceptable.

>
> It seems to me that there are four areas where one might think that
> compromises ought to be made:
>
> 1. Not deploying comsec at all because it's too hard (you allude to this
> later).
> 2. Not deprecating weak algorithms because they are already deployed
> (the case of MD5 and the like)
> 3. Rolling out unauthenticated or opportunistic encryption.
> 4. Rolling out weak algorithms rather than strong ones.
>
> I agree we do 1-3, but my experience is we try pretty hard to avoid #4, and
> that's how I read "breakable encryption".

There were big arguments around this idea included with the SMTP mail
discussions and some even thought this was a consensus statement from
the OS draft, and it is not.  I personally worked to make sure that
statement was not included as a consensus one as there has not been a
specific consensus call on breakable encryption.  It has been
discussed and has been pretty divided.  4 isn't a matter of rolling
new, but really more of 3, keeping existing and not deprecating.

> It's also generally not easier
> to deploy. I think a better way to phrase this would be to say something
> like:
>
> "Perspectives on encryption paradigms have shifted over time to
> incorporporate
> ease of deployment as a high priority, and balance that against providing
> the
> maximum possible level of security regardless of deployment considerations"
>

I'm fine with this wording suggestion.

>>
>> >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 CDNs who have
>> moved to an e2e approach.
>>
>> Here's the updated sentence:
>>The business risk of losing control of content is a motivation outside
>>of privacy and pervasive monitoring that are driving end-to-end
>>encryption for these content providers.
>
>
>>
>> > Transparent intercepting caches that the user
>> > didn't opt into are a bad thing, so having them go away is a positive.
>>
>> The text says authorized parties, so this is referring to caches where
>> there is an agreement in place for this usage.
>
>

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

[Eric Rescorla]

Thank you.

-Ekr


On Wed, Feb 28, 2018 at 9:06 AM, Warren Kumari  wrote:

> On Wed, Feb 28, 2018 at 11:49 AM, Eric Rescorla  wrote:
> > No worries. Looking forward to your thoughts on my comments.
> >
>
> Me too! I've created a repo
> (https://github.com/wkumari/effect-encrypt) where I'll be placing the
> new version to all for easier viewing / diffs.
>
> W
>
>
> > -Ekr
> >
> >
> > On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty
> >  wrote:
> >>
> >> Sorry, I wasn’t able to task switch to editing the document yesterday
> with
> >> other work obligations.
> >>
> >> Best,
> >> Kathleen
> >>
> >> Sent from my mobile device
> >>
> >> On 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. 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 that pair
> >>> of pants.
> >>>---maf
> >>
> >>
> >
>
>
>
> --
> I don't think 

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

[Warren Kumari]

On Wed, Feb 28, 2018 at 11:49 AM, Eric Rescorla  wrote:
> No worries. Looking forward to your thoughts on my comments.
>

Me too! I've created a repo
(https://github.com/wkumari/effect-encrypt) where I'll be placing the
new version to all for easier viewing / diffs.

W


> -Ekr
>
>
> On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty
>  wrote:
>>
>> Sorry, I wasn’t able to task switch to editing the document yesterday with
>> other work obligations.
>>
>> Best,
>> Kathleen
>>
>> Sent from my mobile device
>>
>> On 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. 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 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

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

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

[Eric Rescorla]

No worries. Looking forward to your thoughts on my comments.

-Ekr


On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Sorry, I wasn’t able to task switch to editing the document yesterday with
> other work obligations.
>
> Best,
> Kathleen
>
> Sent from my mobile device
>
> On 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. 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 that pair
>> of pants.
>>---maf
>>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Kathleen Moriarty]

Sorry, I wasn’t able to task switch to editing the document yesterday with 
other work obligations.  

Best,
Kathleen 

Sent from my mobile device

> On 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. 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 that pair
>> of pants.
>>---maf
> 
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

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. 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 that pair
> of pants.
>---maf
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

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

Can you send a link to the Github version? I didn't see a reference?

-Ekr


>
> Confused yet? :-P
>
>
> >
> > 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 that pair
> of pants.
>---maf
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Warren Kumari]

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


>
> 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 that pair
of pants.
   ---maf

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

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

[Warren Kumari]

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.
>
> That doesn't seem up/down. It seems like every other draft I've balloted on
> as an AD :-)
>
> 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.
>>

Me neither!

I think that the IESG chair is the official holder of the state at the
moment, but my 0.02c:

If we get to a no-discuss position (EKR holds the only discuss,
Alissa's is a "supports Ekr's discuss") I would assume that the
Alternate Ballot could be abandoned -- it seems that we would no
longer be deadlocked "by the above procedure".

My personal view is that EKRs comments are helpful and could be easily
folded in - if we do have to ballot, I'd *think* that we are balloting
on the document as written, but that, if it passes, the responsible AD
(me) would take these as useful comments received during IESG eval,
treat the document as "Approved, point raised" and ask for them to be
folded in...

Or something - we are kinda flying blind here.
W





>> 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 that pair
of pants.
   ---maf

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

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

[Spencer Dawkins at IETF]

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.

That doesn't seem up/down. It seems like every other draft I've balloted on
as an AD :-)

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 listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Benoit Claise]

The way I see it, we're going to fix comments forever.
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

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

[Spencer Dawkins at IETF]

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

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

[Eric Rescorla]

Thanks for the updated draft. Some responses below.


On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

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

I continue to think that the term "breakable" is very unfortunate here
(and of course, MD5 isn't breakable "encryption").

It seems to me that there are four areas where one might think that
compromises ought to be made:

1. Not deploying comsec at all because it's too hard (you allude to this
later).
2. Not deprecating weak algorithms because they are already deployed
(the case of MD5 and the like)
3. Rolling out unauthenticated or opportunistic encryption.
4. Rolling out weak algorithms rather than strong ones.

I agree we do 1-3, but my experience is we try pretty hard to avoid #4, and
that's how I read "breakable encryption". It's also generally not easier
to deploy. I think a better way to phrase this would be to say something
like:

"Perspectives on encryption paradigms have shifted over time to
incorporporate
ease of deployment as a high priority, and balance that against providing
the
maximum possible level of security regardless of deployment considerations"


> >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 CDNs who have
> moved to an e2e approach.
>
> Here's the updated sentence:
>The business risk of losing control of content is a motivation outside
>of privacy and pervasive monitoring that are driving end-to-end
>encryption for these content providers.
>


> > Transparent intercepting caches that the user
> > didn't opt into are a bad thing, so having them go away is a positive.
>
> The text says authorized parties, so this is referring to caches where
> there is an agreement in place for this usage.


It says "authorized parties acting on their behalf", but it's not clear to
me on whose behalf. There is a sharp distinction here between the
network operator and the user. Who did you have in mind?



>   CDN's that wish to
> block this behavior have the option to require e2e.  That trend alone
> may be enough to kill this type of service offering.  I don't see why
> it shouldn't be mentioned in terms of it's current use.  What change
> are you looking to see here?
>

I see you added the following text

   It should be noted that caching was first supported in [RFC1945] and
   continued in the recent update of "Hypertext Transfer Protocol
   (HTTP/1.1): Caching" in [RFC7234].

I would rewrite this:

   It should be noted that explicit caching was first supported in
[RFC1945] and
   continued in the recent update of "Hypertext Transfer Protocol
   (HTTP/1.1): Caching" in [RFC7234]. Some operators also operate
   transparent caches which neither the user nor the origin opt-in to.
   The use of these caches is controversial within IETF and is generally
   precluded by the use of HTTPS.






>
> >
> >document existing practices, the development of IETF protocols
> >follows the guiding principles of [RFC1984] and [RFC2804].
> >
> > This is pretty opaque in this context. It should explicitly state that
> > the IETF's 

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 

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

[Kathleen Moriarty]

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 CDNs who have
moved to an e2e approach.

Here's the updated sentence:
   The business risk of losing control of content is a motivation outside
   of privacy and pervasive monitoring that are driving end-to-end
   encryption for these content providers.

> Transparent intercepting caches that 

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

[Randy Bush]

> If the IETF as a community objected to the content of this draft,
> presumably there would ahve been significant dissent during the IETF
> last call.

my memory is that i commented once, supporting christian's eloquence
during ietf last call.  i commented yesterday supporting ekr's
statement.  for those two comments, i have been called a ddos; an ad
hominem shot at the messenger eh?

> It looked to me like the consensus in support of this was rough but
> clear.

not your or my call.

and now in my third ddos on the subject, i think melinda said it well;
this seems to purport to be an ietf position as opposed to an opinion.
as an opinion, it is interesting and useful to document.  as an ietf
position, imiho we have some kilometers to go.

randy

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

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

[Joel M. Halpern]

Let me ask a different version of Carlos (and maybe Randy's) point.

If the IETF as a community objected to the content of this draft, 
presumably there would ahve been significant dissent during the IETF 
last call.

It looked to me like the consensus in support of this was rough but clear.

More importantly, if you think the demonstrated consensus was not in 
support of the document, that is a specific process problem.
If you are saying that in spite of the demonstrated rough consensus, you 
still say that this violates your understanding of the IETF agreement, 
I do not understand how, at this stage of the process, that is your call 
to make?
As Carlos quotes, the existing documents make it clear that their must 
be judgment calls about these issues.
And such a personal consensus interpretation seems even less grounded 
for an informational document aimed, as the abstract states at:


   discusses current security and network operations and management
   practices that may be impacted by the shift to increased use of
   encryption to help guide protocol development in support of
   manageable, secure networks.

If you feel the document does not match its abstract, that is a VERY 
different objection than claiming that the document violates your 
personal take (not demonstrated during IETF last call) on the IETF rough 
consensus.


Yours,
Joel

On 2/8/18 9:08 PM, Carlos Pignataro (cpignata) wrote:



On Feb 8, 2018, at 5:17 AM, Randy Bush  wrote:


Unfortunately, the fundamental concern that motivated my DISCUSS
remains: I do not believe that this document matches the consensus
of the IETF community.

That's an interesting claim.
If the process has not been followed, this requires facts as opposed
to "believes".
We should make sure to make a distinction between the IETF community
views and your own views.


Eric: I’m also interested in understanding your claim regarding consensus — can 
you please expand?



1984 7258


"  Making
networks unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented here.  An
appropriate balance will emerge over time as real instances of this
tension are considered.”


7625 ... and dogged comments on this draft; though some of us
have grew a bit weary of the denial game and allowed ourselves to be
shut up.


Or a DDoS against the ideas on this document?



randy



—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis.”



___
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



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

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

[Carlos Pignataro (cpignata)]

> On Feb 8, 2018, at 5:17 AM, Randy Bush  wrote:
> 
>>> Unfortunately, the fundamental concern that motivated my DISCUSS
>>> remains: I do not believe that this document matches the consensus
>>> of the IETF community.
>> That's an interesting claim.
>> If the process has not been followed, this requires facts as opposed
>> to "believes".
>> We should make sure to make a distinction between the IETF community
>> views and your own views.

Eric: I’m also interested in understanding your claim regarding consensus — can 
you please expand?

> 
> 1984 7258

"  Making
   networks unmanageable to mitigate PM is not an acceptable outcome,
   but ignoring PM would go against the consensus documented here.  An
   appropriate balance will emerge over time as real instances of this
   tension are considered.”

> 7625 ... and dogged comments on this draft; though some of us
> have grew a bit weary of the denial game and allowed ourselves to be
> shut up.

Or a DDoS against the ideas on this document?

> 
> randy
> 

—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis.”


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

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

[Eliot Lear]

On 08.02.18 21:53, Melinda Shore wrote:
> On 2/8/18 5:01 AM, Mirja Kuehlewind (IETF) wrote:
>> Without any judgement, this is an informational document, so it does
>> not necessarily need to have IETF consensus for publication.
> Generally I'm in favor of being pretty relaxed about informational
> documents that describe a real thing in the world, but for better
> or worse this document is taking the form of a position statement
> and I think needs to reflect that position more accurately.

That, I think. is the issue.  This *shouldn't* be a position statement. 
I think it would be good if that were explicit.  It's meant more of a
point of view about some of the problems some folk are facing.

Eliot




signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Melinda Shore]

On 2/8/18 5:01 AM, Mirja Kuehlewind (IETF) wrote:
> Without any judgement, this is an informational document, so it does
> not necessarily need to have IETF consensus for publication.

Generally I'm in favor of being pretty relaxed about informational
documents that describe a real thing in the world, but for better
or worse this document is taking the form of a position statement
and I think needs to reflect that position more accurately.  The
use of the word "consensus" here set my teeth on edge a bit as
we've never had a consensus call specifically on what EKR is
asserting as consensus.  That said, as Randy points out we've got
consensus on a few other documents about encryption and privacy
and I do think that EKR is correct about the overall sense of the
IETF.  Consensus-is-not-voting but it's my very strong impression
that the position being argued in this draft is a minority viewpoint
and I don't think it should be published as-is.

Melinda



signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Mirja Kuehlewind (IETF)]

Without any judgement, this is an informational document, so it does not 
necessarily need to have IETF consensus for publication.

Mirja



> Am 08.02.2018 um 11:17 schrieb Randy Bush :
> 
>>> Unfortunately, the fundamental concern that motivated my DISCUSS
>>> remains: I do not believe that this document matches the consensus
>>> of the IETF community.
>> That's an interesting claim.
>> If the process has not been followed, this requires facts as opposed
>> to "believes".
>> We should make sure to make a distinction between the IETF community
>> views and your own views.
> 
> 1984 7258 7625 ... and dogged comments on this draft; though some of us
> have grew a bit weary of the denial game and allowed ourselves to be
> shut up.
> 
> randy
> 

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

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

[Randy Bush]

>> Unfortunately, the fundamental concern that motivated my DISCUSS
>> remains: I do not believe that this document matches the consensus
>> of the IETF community.
> That's an interesting claim.
> If the process has not been followed, this requires facts as opposed
> to "believes".
> We should make sure to make a distinction between the IETF community
> views and your own views.

1984 7258 7625 ... and dogged comments on this draft; though some of us
have grew a bit weary of the denial game and allowed ourselves to be
shut up.

randy

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

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

[Benoit Claise]

On 2/8/2018 6: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.

That's an interesting claim.
If the process has not been followed, this requires facts as opposed to 
"believes".
We should make sure to make a distinction between the IETF community 
views and your own views.


Regards, Benoit

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

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

[Eliot Lear]

Hi EKR,

Regarding phishing:

> S 5.4.
(I think you mean S 5.3, but this equally applies to section 5.5, so...)
> It's pretty odd to talk about phishing without acknowledging that by
> far the largest anti-phishing platform (Safe Browsing) operates in the
> client, not be network interception

It's not odd at all.  Phishing and spam are intimately related, and one
can't look at Safe Browsing in a vacuum, because one must take into
account the content has already been filtered before it ever gets to the
browser.  Hint: it's a lot.  According to Talos, the average daily
volume of spam in January was 421 billion messages, of which some
fraction were phish(*).  While there are a number of techniques that do
NOT require access to the body of a message, such as honeypots, there
are others that do.  Just two examples out of many: URLs who themselves
have bad reputations, and  hash busters whose job it is to ruin the day
of a Bayesian filter.

Also, your use of the word "network interception" here is partially
misplaced.  The mail architecture itself relies on intermediaries, and
it is best practice to use them.  None of this addresses spear phishing,
which is very difficult to spot, but requires forensic analysis to clean
up after.  Again, the intermediaries in the architecture play a key role.

Eliot
(*) Different people count differently, but the number is always large.



signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eric Rescorla]

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


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.


   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.  Transparent intercepting caches that the user
didn't opt into are a bad thing, so having them go away is a positive.

   document existing practices, the development of IETF protocols
   follows the guiding principles of [RFC1984] and [RFC2804].

This is pretty opaque in this context. It should explicitly state that
the IETF's position is that we do not engineer for these use cases,
not just to cite the RFCs.


   based billing, or for other reasons, possibly considered
   inappropriate by some.  See RFC7754 [RFC7754] for a survey of
   Internet filtering techniques and motivations.  This section is

I don't think this accurately represents the RFC, which makes clear
that the IAB consensus is that filtering is bad:

" From a technical perspective, there are no perfect or even good
solutions -- there is only least bad.  On that front, we posit that a
hybrid approach that combines endpoint-based filtering with network
filtering may prove least damaging.  An endpoint may choose to
participate in a filtering regime in exchange for the network
providing broader unfiltered access."


   detect or prevent attacks as well as to guarantee service level
   expectations.  In some cases, alternate options are available when
   encryption is in use, but techniques like that of data leakage

These certainly are use cases, but you really need to acknowledge that
it's also a form of user surveillance.


   Some DLP tools intercept traffic at the Internet gateway or proxy
   services with the ability to man-in-the-middle (MiTM) encrypted
   session traffic (HTTP/TLS).  These tools may use key words important
   to the enterprise including business sensitive information such as
   trade secrets, financial data, personally identifiable information
   (PII), or personal health information (PHI).  Various techniques are
   used to intercept HTTP/TLS sessions for DLP and other purposes, and
   are described in "Summarizing Known Attacks on TLS and DTLS"
   [RFC7457].

As far as I know, the MITM techniques used by middleboxes are not
described in 7457.

You also need to cover the fact that these MITM are a threat to user
security because they are often so badly implemented.


S 5.4.
It's pretty odd to talk about phishing without acknowledging that by
far the largest