Subject: Re: Last Call: <draft-mm-wg-effect-encrypt-13.txt> (Effect of Pervasive Encryption on Operators) to Informational RFC

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 12 Nov 2017 19:55:10 +0800

On Mon, Nov 06, 2017 at 06:06:50AM -0800,
 The IESG <[email-masked]> wrote 
 a message of 37 lines which said:

> The IESG has received a request from an individual submitter to
> consider the following document: - 'Effect of Pervasive Encryption
> on Operators' <draft-mm-wg-effect-encrypt-13.txt> as Informational
> RFC

I'm quite concerned by this document. Basically, it seems to me it
deviates a lot from a simple description of current practices, and
goes into promoting them. The overall effect seems to me very
dangerous. One can easily read this document as "encryption is a pain
for the operators, we should not promote it too agressively".

My opinion is that its publication as it is would inflict real harm to
the efforts of IETF to promote privacy (which implies, among other
things, a lot of encryption).

The document also completely ignores network neutrality, not to
mention the end-to-end principle.

More precisely:

> This document discusses practices currently used by network
> operators to manage, operate, and secure their networks

Actually, it does not "discuss": it describes them, using only the
arguments of the operators that use these practices, rarely
questioning them.

> the impact of pervasive encryption

Note that we are far from "pervasive encryption". For instance, the
DNS traffic is almost entirely in clear (RFC 7858). 

> For example, the traffic patterns between server and browser are
> dependent on browser supplier and version

That's a good example of why HTTP sessions must be encrypted: the
User-Agent: field is very revealing, among other infos sent by the
browser, as exemplified by the Panopticlick
<https://panopticlick.eff.org/>

> Network operators use packet captures and protocol-dissecting
> analyzers when responding to customer problems,

Not all network operators are so benevolent. I doubt that many 30 $ or
25 € / month ISP use tcpdump when the customer has a
problem :-) Seriously, this sentence is very dangerous because of:

> The ability to identify the problem application's traffic is
> important and deep packet inspection (DPI) is often used for this
> purpose

This really looks like an attempt to "sell" DPI by explaining that it
may benefit the users. Actually, I would like to see my ISP going into
such efforts to help me but I doubt it will be the case. 

Note that no ISP document the practices it actually use against user
flows. This is sufficient proof that they are not done in the interest
of the users.

> For example, by investigating packet loss (from TCP sequence and
> acknowledgement numbers), round-trip-time (from TCP timestamp
> options or application-layer transactions, e.g., DNS or HTTP
> response time), TCP receive-window size, packet corruption,
> inefficient fragmentation, or application-layer problems, the
> operator can narrow the problem

Almost all of these investigations can be performed even if TLS or SSH
is used. Again, it really seems an effort to make DPI acceptable.

> Because of this, application server operators using increased
> encryption should expect to be called upon more frequently to assist
> with debugging and troubleshooting

Hard to read this as something else than a threat "do not use
encryption or your business will suffer".

> A common, early trigger for DDoS mitigation includes observing
> uncharacteristic traffic volumes or sources; congestion; or
> degradation of a given network or service.  One approach to mitigate
> such an attack involves distinguishing attacker traffic from
> legitimate user traffic.

Are there really dDoS attacks using encryption? Hard data welcome.

> Mobile networks especially rely on content/application based
> prioritization of Over-the-Top (OTT) services

This is a very important point: if encryption really prevents
prioritization of some services over the others, then it means we need
more encryption, not less. If encryption can help preserve network
neutrality, this is a good reason to use it even more.

> Due to the characteristics of the mobile link, performance-enhancing
> TCP proxies may perform local retransmission at the mobile edge.  In
> TCP, duplicated ACKs are detected and potentially concealed when the
> proxy retransmits a segment

Again, TLS or SSH do not prevent this sort of hacks.

> In addition to caching, various applications exist to provide data
> compression in order to conserve the life of the user's mobile data
> plan and optimize delivery over the mobile link

I know that some mobile operators (see, in french,
<https://www.hteumeuleu.fr/la-compression-dimages-par-les-operateurs/>)
apply a LOSSY compression without the user consent or even
knowledge. Again, if end-to-end encryption prevents this, this is a
very good reason to deploy encryption.

> These regulations include Lawful Intercept, adherence to Codes of
> Practice on content filtering, and application of court order
> filters.  Such regulations assume network access to provide content
> filtering and accounting, as discussed below.

It seems to me that RFC 1984 already replies to this reasoning.

> This type of granular filtering could occur at the endpoint.
> However, the lack of ability to efficiently manage endpoints as a
> service reduces providers' ability to offer parental control.

I would be specially unhappy if IETF were to publish a RFC with such a
sentence without follow-up comments. Filtering MUST be done at the
endpoint, otherwise it is not a service, it is censorship.

If we assume that the subscriber wants parental control, then we must
conclude that he/she will have no problem sending the traffic to a
filtering proxy. No need to break encryption for that.

> Some mobile carriers use HTTP header insertion (see section 3.2.1 of
> [RFC7230]) to provide information about their customers to third
> parties or to their own internal systems [Enrich].

Again, this technique, which has very serious privacy consequences
(see the mentioned reference [Enrich] with for example Vodafone which
added the phone number and the IMEI in HTTP headers) MUST NOT be done
and, if encryption stops it, great.

Editorial issues:

> Currently, some mobile network service providers redirect the
> customer using HTTP redirect to a page that explains to those
> customers the reason for the blockage and the steps to proceed

A mention of RFC 6108 would be cool here.

> monitor incoming mail to remove SPAM

Why is spam uppercased?

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Nov 2017 21:02:04 +0800

I concur with most of Stephane’s comments. And I find the use of the term “pervasive encryption” very problematic. Pervasive means:

“(especially of an unwelcome influence or physical effect) spreading widely throughout an area or a group of people.”

More encryption is never unwelcome to the enduser.

If this document listed these practises, along with valid methods for operators to switch to, i could be convinced the document is useful. But as Stephane pointed out, a lot of these problems are desired features. That the operator has less networking debugging tools is an unavoidable side effect, but should not be used as an argument against more encryption.

But in its current form, it seems this document would be prime candidate for operator misbehaviour justification “sanctioned” by the IETF. 

Note that I _do_ believe in the authors’ good intention of just documenting the new problems operators face. But the IETF will have taken these issues into consideration already before it published the RFCs.

This documents feels (unintentionally) that we need to go back to be drawing board to reconsider these operator issues.

Paul

> On Nov 12, 2017, at 19:55, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: S Moonesamy <[email-masked]>
Date: Sun, 12 Nov 2017 13:43:27 -0800

Hello,
At 06:06 AM 06-11-2017, The IESG wrote:
>The IESG has received a request from an individual submitter to consider the
>following document: - 'Effect of Pervasive Encryption on Operators'
>   <draft-mm-wg-effect-encrypt-13.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2017-12-04. Exceptionally, comments may be

On reading the draft, I wondered whether the authors of the draft 
have an opinion about "responsible encryption".

In Section 1.1:

   "OS has been implemented as NULL Authentication with IPsec [RFC7619]
    and there are a number of infrastructure use cases such as server
    to server encryption, where this mode is deployed."

It is possible to find use cases of deployment.  That does not mean 
that it is always a good idea.

In Section 2:

   "This and other increases in the use of encryption had the immediate
    effect of helping protect the privacy of users' data, but created a
    problem for some network management functions."

Is this about privacy or is it about a security loophole?

In Section 2.1.2:

   "The ability to identify the problem application's traffic is
    important and deep packet inspection (DPI) is often used for
    this purpose."

Is debugging choppy video the main purpose of DPI?  Why should 
perversive surveillance software/hardware be used to debug application issues?

In Section 2.3:

   "These regulations include Lawful Intercept, adherence to Codes of
    Practice on content filtering, and application of court order filters."

Are the "Codes of Practices" part of regulations?  Are there 
references to those Codes of Practices?

In Section 3.2.2:

   "STARTTLS ought have zero effect on anti-SPAM efforts for SMTP traffic."

I doubt that STARTTLS cause any significant problem as the receiver 
has the ability to inspect emails.

In Section 4.1.1:

   "detect and defend against Internet DDoS attacks, including both
    volumetric and layer 7 attacks."

Does the IETF use the OSI layer (re. layer 7)?

As an overall comment, there are many uses of "many" in the 
document.  I read the entire document.  I understand that the authors 
may have put a lot of effort in this work.  However, I preferred to 
reduce the effort as it was a bit tedious to do a detailed 
review.  The title of the document is "Effect of Pervasive Encryption 
on Operators". Is this document about making the case against RFC 7258?

Regards,
S. Moonesamy

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 12 Nov 2017 22:33:31 -0600

> More encryption is never unwelcome to the enduser.

As the originator of the "pervasive encryption" term, I suppose I am obligated
to respond.  Though first I must note that absolute statements such as
"is never unwelcome" are risky positions to take, seeing as they are
undermined by even a single counterexample.

The idea for the "pervasive encryption" phrase stems from the use of
widespread encryption as a countermeasure against pervasive monitoring.
The somewhat negative ("unwelcome") connotation is not a primary motivator
for the use of the term, but does provide a secondary effect of making the
reader consider whether seeking ubiquitous encryption might have some downsides.
Alternatives such as "ubiquitous" or "widespread" encryption were not necessarily
appropriate, given that they could be seen as making claims about a current
state of affairs that would not be borne out by the facts.

I do not claim to have a solid, concrete, answer to the question of whether
there are downsides to seeking ever-increasing levels of encryption, but
am willing to admit the possibility of at least some localized downsides.

That said, please do not take my statements as an endorsement of the
current document overall.

> Note that I _do_ believe in the authors’ good intention of just documenting the new problems operators face. But the IETF will have taken these issues into consideration already before it published…

I do sympathize with your concerns here.

-Ben

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 13 Nov 2017 00:40:30 -0500

Hello,

Thanks for your comments on the draft.  We will respond to all
comments, but it may take time as it's a busy week and this message
seemed like one that I could respond to more quickly than the prior.

> More encryption is never unwelcome to the enduser.

Could you propose an alternate title?  We used the term ubiquitous
previously, and it was changed in a prior IETF list discussion to the
current title.

> If this document listed these practises, along with valid methods for operators to switch to, i could be convinced the document is useful. But as Stephane pointed out, a lot of these problems are d…

The purpose was to document the effects of increased encryption, not
to solve any of the problems. As the document states, there are cases
where the feature/function may just be eliminated with no way to
perform the desired feature (desired by some operators).  If you don't
look at the impacts as a first step, they will be an impediment to the
adoption of E2E protocols and the evolution that is happening with TLS
1.3 and QUIC for example.  By opening up the conversation, and having
both sides look at the problems, we are more likely to achieve E2E in
deployment scenarios.  Continuing an arms race is not effective -
rather stepping back to document impacts is a first step toward
removing obstacles to deployment for E2E.

I thought this point was fairly clear in the introduction, so if it is
not and you have wording suggestions, please provide them.

> But in its current form, it seems this document would be prime candidate for operator misbehaviour justification “sanctioned” by the IETF.

The introduction makes it quite clear that it is not the case and
states the documented effects are not IETF sanctioned.

> Note that I _do_ believe in the authors’ good intention of just documenting the new problems operators face. But the IETF will have taken these issues into consideration already before it published…

Operators have responded very positively to this draft that has let
them open up the conversation, so I don't think the problems have been
looked at by the developers of protocols like TLS 1.3 and QUIC.
Operators were unaware of the changes.  Now it's time to have the
discussions and see how we can work together so that deployment of e2e
encryption happens.  Just because we release protocols does not ensure
their adoption.

> This documents feels (unintentionally) that we need to go back to be drawing board to reconsider these operator issues.

Not necessarily.  The framing tries to make the intentions clear.  Can
you take a look at the introduction and let us know where that is not
clear?

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 13 Nov 2017 00:54:25 -0500

SM, thanks for your review of this draft.

On Sun, Nov 12, 2017 at 4:43 PM, S Moonesamy <[email-masked]> wrote:
> On reading the draft, I wondered whether the authors of the draft have an
> opinion about "responsible encryption".

The authors are concerned with user privacy and obstacles to deploying
encryption.  If the obstacles are not documented and discussed,
adoption of encryption could suffer.
There is a statement in the introduction about operators being
interested to protect end user privacy and this has been repeated by a
number of contributing operators.  The desire to document the impacts
to their current operations is a positive one as they need help to
figure out if there are other ways to achieve the goal of the
described functions in new ways or if it just won't be possible.

> It is possible to find use cases of deployment.  That does not mean that it
> is always a good idea.

I'd be hesitant to add text that says it doesn't mean it's a good idea
as that would feed into the assumptions being made in this thread that
this draft is trying to prevent the deployment of encryption, when it
is just the opposite.  Unless you mean that there should be a
statement that authenticated encryption is preferred?

> Is this about privacy or is it about a security loophole?

That could depend on the content of data exposed.  Are you suggesting
a text change?

> Is debugging choppy video the main purpose of DPI?  Why should perversive
> surveillance software/hardware be used to debug application issues?

If you break this sentence apart, the "import" part is the ability to
identify problems in application traffic.  Many applications do a poor
job of logging, so DPI is sometimes used.  A solution would be to
improve logging and debugging in applications, which is suggested in
the draft as an answer to many of the documented effects.  I'm not
sure I follow your second question or what text led you to the
question?  I read this sentence as saying it is one way it is done
today, because it is not working to do this directly with debug
information from the application.  I read this as documenting what is
done and it leads me to think that applications need to improve their
debugging and logging capabilities.

> Are the "Codes of Practices" part of regulations?  Are there references to
> those Codes of Practices?
>
> In Section 3.2.2:
>
> I doubt that STARTTLS cause any significant problem as the receiver has the
> ability to inspect emails.

So you agree with this statement?  Or are you asking a question?  If
you could clarify, I would appreciate it.

> As an overall comment, there are many uses of "many" in the document.  I
> read the entire document.  I understand that the authors may have put a lot
> of effort in this work.  However, I preferred to reduce the effort as it was
> a bit tedious to do a detailed review.  The title of the document is "Effect
> of Pervasive Encryption on Operators". Is this document about making the
> case against RFC 7258?

You may want to take another read of RFC7258.  This is a early step in
one of the stated goals of that document - to find a balance between
protections and the ability to perform network management by
documenting the impacts to serve as a start to that conversation.

-- 

Best regards,
Kathleen

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 01:30:43 -0500

Kathleen,

> previously, and it was changed in a prior IETF list discussion to the

The general definition when comparing various dictionaries seems to
associate the word "pervasive" with the common meaning of "spread
throughout".

Based on that, the title seems appropriate.

regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 02:12:07 -0500

> removing obstacles to deployment for E2E.

This was my understanding as well and seems like a very rational and
healthy way of achieving the overall desires stated in RFC7258.
Documenting the realities of production networks is needed.

> not and you have wording suggestions, please provide them.

It seems clear to me.

> encryption happens.  Just because we release protocols does not ensure

These are very important points.  If we want to to see our efforts on
E2E encryption realized, ensuring deployability is important. Ignoring
the operator side of the equation (which effectively connects the user
to the Internet) would seem like a problematic approach.  If we want
happy end users, then performance along with encryption (among other
things) are needed (not one in exclusion of the others).

The Internet is a complex place (with its massive collection of
distinctive networks, users, and applications).  Introducing changes
is not a simple task and oversimplifying what we need to do to affect
the right change will not equate to the end goals we want to achieve.

The draft is documenting challenges we should consider as we conduct
our work.  I don't see how this is a problem.

regards,

Victor K

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Nov 2017 16:08:08 +0800

Since we're talking about the title, I had a different reaction to it; currently, it reads as if *all* operators are necessarily affected by pervasive encryption. 

In the discussions I've had, the great majority of operators have said they are not affected by pervasive encryption (YMMV, of course), so I wonder if a title like "Reported Effects of Pervasive Encryption on Operators" or "Effects of Pervasive Encryption Purportedly Encountered by Some Operators" would be more appropriate. 

Even then, many of the areas discussed lack important context about whether or not there are other options to achieve the same goal, and how prevalent their use by operators is. For example, the sections on Content Compression and Content Encryption beg these questions. 

It might be useful to have a list of potential effects on network operators without that context, but some of the items still seem to be written in a way that assumes the intrinsic value and uniqueness of the technique being discussed (e.g., Performance Enhancing Proxies), which can be deeply misleading (despite the attempt at positioning in the Introduction). If this were Wikipedia, I'd say there were several NPOV issues remaining here.

A few more comments:

1. Introduction - "Ideally, new methods could be developed to accomplish the goals of current practices despite changes in the extent to which cleartext will be available to network operators." It's not at all clear that this would be ideal, since the goals of some of the documented practices are quite questionable, both technically and ethically.

2.2.5 Caching and Content Replication Near the Network Edge - "Web proxies are widely used [WebCache]" -- the reference covers four US-based mobile networks, only two of which deployed caching (table 1), so it's hardly supporting this claim, and the claim itself is about proxies, not caching. Forward proxy caching (which is the relevant thing here) has been steadily declining in deployment for years, partially because of the increased deployment of encryption, but also because content providers don't trust forward proxies; they have a reputation of too often taking liberties with serving stale responses.

2.2.5 Caching and Content Replication Near the Network Edge - "... and caching is supported by the recent update of "Hypertext Transfer Protocol (HTTP/1.1): Caching" in [RFC7234]."  Caching was first supported by RFC1945, HTTP/1.0.

2.3.4 HTTP Header Insertion - I'm deeply uncomfortable with having this text in an IETF document without a LOT more context.

4.1.3.3  HTTP Service Calls - This is confusing; it it talking about sniffing the back-end service calls, or the original request? 

Cheers,

> On 13 Nov 2017, at 2:30 pm, Victor Kuarsingh <[email-masked]> wrote:
> 
> Kathleen,
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 13 Nov 2017 11:11:46 +0000

Hi,

This is a very important document and a clear step forward towards long-term deployable security, by documenting the effects of pervasive encryption on network operations and management.

As RFC 7258 writes:

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

And document effects, positive or negative, on existing network operational and management practices is indeed starting to consider those real instances.

RFC 7258 further says:

  "While PM is an attack, other forms of monitoring that might fit the
   definition of PM can be beneficial and not part of any attack, e.g.,
   network management functions monitor packets or flows and anti-spam
   mechanisms need to see mail message content.  […]"

Consequently, if beneficial mechanisms are adversely affected (degraded or flat-out broken) in presence of pervasive encryption, documenting is the first step.

For example, if a provider uses passive performance measurement metrics and methods techniques, developed by the IETF (e.g., IPPM), in order to perform SLA management and verification, and that is negatively affected, the first step is to document those effects.

Interestingly, another draft explores a subset of this topic: https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-03

For example, Section 3 says:

  "This section identifies ways that actors can benefit by observing
   (non-encrypted) transport header fields at devices in the network.”

And analysis what would happen if access to granular transport header information is not available. The implications are the need to build new tools, new methods, use active vs. passive approaches, all of which require time and money (and potentially new protocol).

This draft also includes the following text, which describes these effects:

  "The common language between network operators and application/content
   providers/users is packet transfer performance at a layer that all
   can view and analyze.  For most packets, this has been transport
   layer, until the emergence of QUIC, with the obvious exception of
   VPNs and IPsec.  When encryption conceals more layers in a packet,
   people seeking understanding of the network operation need to rely
   more on pattern inferences and other heuristics.”

Consequently, the real (second order) effect is lack of common vocabulary and language between app providers and network operators.

It seems some use-cases listed in this draft can be added to draft-mm-wg-effect-encrypt as well (although I believe all broad categories are covered).

There is one additional approach not considered in draft-mm-wg-effect-encrypt: leverage RFC 5706 more. For example, https://tools.ietf.org/html/rfc5706#section-2.5

  "The introduction of a new protocol or extensions to an existing
   protocol may have an impact on the operation of existing networks.
   Protocol designers should outline such impacts (which may be
   positive), including scaling concerns and interactions with other
   protocols."

Perhaps one start is a tighter look at Manageability Considerations.

A few additional comments on the draft itself.

https://tools.ietf.org/html/draft-mm-wg-effect-encrypt-13

Abstract:

  "This document discusses current
   security and network 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."

The Abstract and various other paragraphs talk about “management practices”. However, that ought to be broadened to “operations and management practices” throughout, both of which make up manageability.

I believe this is the right text (from the Introduction), which should be mirrored in the Abstract and elsewhere — “manage, operate, and secure":

  "This document discusses practices currently used by network operators
   to manage, operate, and secure their networks and how those practices
   may be impacted by a shift to increased use of encryption."

Section 2.2. describes effects on traffic optimization and management, including some “service functions”.

What it doesn’t describe is “service function chaining” (i.e., the ordered steering and application of those optimizations). If the network visibility goes from a 5-tuple to a 2-tuple, or if everything above the transport becomes unaccessible, then a Classifier (RFC 7665) in a service function chain will not be able to perform its job, and the service function path will be adversely affected.

At the same time it is important that there are mechanisms provided to protect security and privacy — in this example, the layer underneath a network service header can be protected with session encryption. A goal is protecting end-user data — but at the same time not making the network inoperable or unmanageable.

As a closing note, a real power and differentiation of the IETF is cross-area synergies. This topic should become a bridge and not a division.

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

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

On Nov 6, 2017, at 10:06 PM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2017-12-04. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

  Pervasive Monitoring (PM) attacks on the privacy of Internet users is
  of serious concern to both the user and the operator communities.
  RFC7258 discussed the critical need to protect users' privacy when
  developing IETF specifications and also recognized making networks
  unmanageable to mitigate PM is not an acceptable outcome, an
  appropriate balance is needed.  This document discusses current
  security and network 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.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Nov 2017 20:47:08 +0800

> 1. Introduction - "Ideally, new methods could be developed to accomplish the goals of current practices despite changes in the extent to which cleartext will be available to network operators." It'…

Can you please explain what you mean by that last statement?  I ask
because the statement leads us to a dead end when it is not qualified,
rather than a way forward to address what you might think "legitimate"
problems to solve. 

Eliot

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 13 Nov 2017 09:06:27 -0500

> In the discussions I've had, the great majority of operators have said they are not affected by pervasive encryption (YMMV, of course), so I wonder if a title like "Reported Effects of Pervasive En…

I don't think we have enough data to put any quantitative value on
this.  What we have is a list of considerations / issues based on
input.  Suggesting "some" would be as erroneous as suggesting "many".
The current titles seems to be neutral in this regard.

I don't have any specific issues with adding work "Reported" in title,
but does that really add any intrinsic value to the reader? (assuming
one reads the draft and does not stop at the title).

> Even then, many of the areas discussed lack important context about whether or not there are other options to achieve the same goal, and how prevalent their use by operators is. For example, the se…

It's possible solutions deployed by operators may have other technical
options, however we lack the full set of data to make claims that
other options can be used, or if so, what obstacles need to be
overcome to change deployments.  There would likely be both technical
and business factors those entities need to address to change things.

Even if there is agreement and a desire to change things, it often
takes time to change production networks which means items listed are
factors for consideration.

> It might be useful to have a list of potential effects on network operators without that context, but some of the items still seem to be written in a way that assumes the intrinsic value and unique…

Who do we think we are misleading?  The section seems to describe
proxies used in mobile networks to deal with real performance issues
related to that access network type.  As a former mobile network
architect and operator, I don't see an issue with what is described.
There are real latency issues to deal with there and this is one way
some have dealt with them.  Even within a single mobile provider's
network, there are often varying technical challenges to deal with
from market to market.

regards,

Victor K

---

From: Roni Even <[email-masked]>
Date: Mon, 13 Nov 2017 14:40:42 +0000

Inline
Roni

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: יום א 12 נובמבר 2017 15:02
> To: Stephane Bortzmeyer
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-mm-wg-effect-encrypt-13.txt> (Effect of
> Pervasive Encryption on Operators) to Informational RFC
> 
> 
> 
> I concur with most of Stephane’s comments. And I find the use of the term
> “pervasive encryption” very problematic. Pervasive means:
> 
> “(especially of an unwelcome influence or physical effect) spreading widely
> throughout an area or a group of people.”
> 
[Roni Even] I will argue this statement.  My experience is that the user care about the encryption of his content. As for privacy - do you see users stop using social media? Do they install applications that ask  for access to you contact, photos, location or like most users they just approve them.
> 
> If this document listed these practises, along with valid methods for
> operators to switch to, i could be convinced the document is useful. But as
> Stephane pointed out, a lot of these problems are desired features. That the
> operator has less networking debugging tools is an unavoidable side effect,
> but should not be used as an argument against more encryption.
> 
> But in its current form, it seems this document would be prime candidate for
> operator misbehaviour justification “sanctioned” by the IETF.
> 
> Note that I _do_ believe in the authors’ good intention of just documenting
> the new problems operators face. But the IETF will have taken these issues
> into consideration already before it published the RFCs.
> 
> This documents feels (unintentionally) that we need to go back to be
> drawing board to reconsider these operator issues.
> 
> Paul
> 
> > On Mon, Nov 06, 2017 at 06:06:50AM -0800, The IESG
> > <[email-masked]> wrote a message of 37 lines which said:
> >
> >> consider the following document: - 'Effect of Pervasive Encryption on
> >> Operators' <draft-mm-wg-effect-encrypt-13.txt> as Informational RFC
> >
> >> This document discusses practices currently used by network operators
> >> to manage, operate, and secure their networks
> >
> > 25 € / month ISP use tcpdump when the customer has a problem :-)
> > Seriously, this sentence is very dangerous because of:
> >
> options
> >> or application-layer transactions, e.g., DNS or HTTP response time),
> >> TCP receive-window size, packet corruption, inefficient
> >> fragmentation, or application-layer problems, the operator can narrow
> >> the problem
> >
> > <https://www.hteumeuleu.fr/la-compression-dimages-par-les-
> operateurs/>
> > ) apply a LOSSY compression without the user consent or even

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 14 Nov 2017 10:58:03 +0800

> On 13 Nov 2017, at 8:47 pm, Eliot Lear <[email-masked]> wrote:
> 
> 
> 

I mean that the word "ideally" is not really appropriate here. This sentence should be dropped, or modified to remove that implication.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Nov 2017 11:35:59 +0800

> I mean that the word "ideally" is not really appropriate here. This sentence should be dropped, or modified to remove that implication. 

What I am asking is this: what is technically or ethically quesitonable?

Thanks,

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 14 Nov 2017 11:37:33 +0800

> The current titles seems to be neutral in this regard.

I disagree; "effect" implies it's complete and always encountered; it reads as "*The* effect".

> one reads the draft and does not stop at the title).

To be explicit -- part of my problem with this draft as written is that it's pretty obviously had significant edits to the Introduction to try to re-cast it and address the concerns raised, but the body of the text (as well as the title) have not been changed to align with that. As such, someone reading isolated parts of the RFC (yes, that happens) could be mislead about the IETF's position on these things.

The title goes a long way to setting the stage for how someone reads a document; it's what shows up in citations.

> factors for consideration.

My point is that in some cases, the goals listed may be met by parties other than operators, and that's worth mentioning.

> network, there are often varying technical challenges to deal with

The term "Performance-Enhancing Proxy" generally refers to a number of different techniques (as RFC3135 explains). Amongst people who run services, PEPs are widely known to cause problems with performance, rather than enhance it, because many operators deploy and forget them. Having an appliance that's optimising the 2017 Internet for conditions in 2005 isn't helping. Saying that the technique "measurably improves" it (the draft's words) isn't the whole story.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 14 Nov 2017 11:42:29 +0800

> On 14 Nov 2017, at 11:35 am, Eliot Lear <[email-masked]> wrote:
> 
> 
> 

- HTTP header insertion / "enrichment" (in many scenarios)
- Content filtering (to some people, in some situations)
- Performance-enhancing proxies (in some deployments, as they add to ossification)
- Customer access monitoring (to some people, in some situations)
- Content compression (depending on how it's interposed)

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 13 Nov 2017 22:59:32 -0500

Dear Stephane,

Thank you for your review and comments.  Let's see if we can work
through your questions, discuss updates and perspectives to see where
we get.  I appreciate your engagement in advance.

Inline

> for the operators, we should not promote it too agressively".

We worked hard on the framing in the introduction, so I'd like to see
if your concerns are captured there in this discussion or if wording
tweaks to make sure the statements are read as explanations of what is
in use as opposed to endorsements as they are not.  This is meant as a
starting point for discussion to find balance between network
management and prevention of pervasive monitoring, which is called for
in RFC7258.  We as a community have to work through these discussions
to determine where the balance lies.  This type of conversation and
ones that would follow based on this and other work is helpful toward
that goal.

> things, a lot of encryption).

I think wording tweaks may help, so let's see where we get as this is
an important conversation to have.  As one of the SecADs, I am
constantly reviewing drafts and identifying security and privacy
issues with new and evolving protocols.  Acknowledging what practices
are in place is very important to determine next steps and to work
toward a common goal of privacy.  Note that many of the techniques are
aimed at network management and not with the intent of exploiting end
user privacy. Operators are also concerned with end user privacy and
in many cases, the end point application is actually the biggest risk
to that user's privacy.  Many of the use cases described are working
towards use of a 5-tuple or 2-tuple or limited data that has been
exposed at the transport layer.  Yes, identifiers and flow information
can be be used to expose information on end users.

It is also clear that at least several of the described use cases
could be solved with improved logging and debugging at the
application.  This is a known gap that if we worked together to
address could help with a shift towards increased deployment of e2e
encryption.

> mention the end-to-end principle.

Perhaps a text change to highlight this better might help.  The E2E
principle is referenced with 3 RFCs in the second paragraph of the
Introduction.  When this was added, I had suggested that it might be a
stronger statement to separate out the e2e references into a separate
subsequent sentence since the documents don't quite fit with the
preceding references. The IESG (in their review) did not think that
was necessary, so we have the current text.  I think it might be
helpful to pull this out separately as you missed it's presence and
others will likely too.  It's also important to note, that like this
document, the three on the e2e are informational and thus do not
represent IETF consensus. So, they probably don't fit with the
sentence they were in anyway since they are BCPs or policy documents
(2804). RFC1958 is informational, but does offer guidance that is not
immutable, so I think it's fine to leave where it is, but could see
how that might be debatable.  E2E is a guiding principle, the existing
documents encourage it's use, document use cases, but explicitly do
not make recommendations.

Here's a proposal, edit suggestions are welcome, of course:

OLD:

   The document does not endorse the use
   of the practices described herein.  Nor does it aim to provide a
   comprehensive treatment of the effects of current practices, some of
   which have been considered controversial from a technical or business
   perspective or contradictory to previous IETF statements (e.g., [RFC
   1958], [RFC 1984], [RFC 2804], [RFC 2775], [RFC 3724], [RFC 7754]).

NEW:

   The document does not endorse the use
   of the practices described herein.  Nor does it aim to provide a
   comprehensive treatment of the effects of current practices, some of
   which have been considered controversial from a technical or business
   perspective or contradictory to previous IETF statements (e.g., [RFC
   1958], [RFC 1984], [RFC 2804]).
   The following informational documents consider the end to end (e2e)
architectural principle, a guiding principle for the development of
Internet protocols [RFC 2775], [RFC 3724], [RFC 7754]).

> arguments of the operators that use these practices, rarely

Good catch, thanks. How about:
s/discuss/documents/

> DNS traffic is almost entirely in clear (RFC 7858).

This discussion has continued in the larger thread, so I'll follow
along there to see if the end result is to change to a new term or if
this term has agreement.  If you have proposals for alternate terms,
please do add them to that discussion.  Thank you.

> <https://panopticlick.eff.org/>

Sure, that's not being argued.  If you think a text change would help
to make it clear that this is just being documented, please suggest
text.  The statement above reads as documentation of use to me, not an
argument in either direction, but if you read it in another way, a
clarification might be helpful.  We're happy to consider proposals and
discuss on list.

> problem :-) Seriously, this sentence is very dangerous because of:

I think the rest of your thought was omitted, but I believe this was
discussed further in the thread.  I will wait to see if text
adjustments are needed.  As far as I recall of the list discussion,
"some" being added didn't seem to help as that is already implied with
the existing sentence. Other text modification suggestions are welcome
to help resolve a concern, if one exists still.

> such efforts to help me but I doubt it will be the case.

I believe I responded to this point later in the thread, so I won't
respond here too.  I suggest this gets snipped in a response.

> flows. This is sufficient proof that they are not done in the interest

Hmm, or this is because it's part of their secret sauce to provide
enhanced performance over a competitor to meet or exceed SLAs for
which contract services are based on and that allows them to continue
to sell bandwidth and operate networks for which applications rely
upon.

> is used. Again, it really seems an effort to make DPI acceptable.

The draft acks that some of the practices rely on the use of a 2-tuple
or 5-tuple.  You're arguing that a 5-tuple is enough for this
particular type of monitoring that is documented. Is the expanded text
around this statement contradictory to that point?  If so, do you have
a text suggestion to clarify?  I think the description of what
metadata is used in the quoted text makes your point clear already,
but if you are reading it otherwise, others may too.

> encryption or your business will suffer".

Hmm, what text would you suggest?  This points to a problem that we
have currently in that applications are not providing adequate logging
and debugging information.  To be successful in expanding the use of
e2e, it is necessary to address this gap.  Is there a way to rephrase
this text, but still convey this point so you don;t feel like it's a
threat?  It's meant to be a possible way forward.

> Are there really dDoS attacks using encryption? Hard data welcome.

This text was provided by 3 contributors (in ack section) with hands
on experience on DDoS attacks.  I can understand why you might
question why encryption would be used as it would seem unnecessary,
but it could be targeting services that are encrypted to deplete
resources.  the important point here is the ack that a fingerprint of
encrypted traffic is adequate to identifying DDoS traffic to assist
with mitigation.  If you are arguing the e2e principle, I'm not sure
why you'd be concerned with this statement where a type of monitoring
has been able to proceed in an encrypted world and serves as a good
example.

> neutrality, this is a good reason to use it even more.

This is a technical summary, nit a policy one.  So if we were to dive
into net neutrality, we'd have to understand how they were
prioritizing services.  Is this based on paid SLAs with large
customers, which would mean that it doesn't enter the net neutrality
space.  Is it to prefer their services over competitors?  For this
case, it is a problem.  If it is to prefer services that do not have a
tolerance for latency, like weighting phone calls over email, is this
just normal traffic management to ensure things like emergency calls
are given a preference?

I'd have to go back and look at the surrounding text.  If you have a
text proposal here, please let us know.  We're interested to document
uses of monitoring, not to make policy statements or recommendations
as this is intended to be an informational document.  If there are
references to other statements that already provide such guidance, I
think it would be better to include a link rather than trying to work
toward consensus on any such statement in this draft.  This one
clearly states the practices documented are not endorsed and I think
that should address your concern.  Having said that, if you do have a
wording suggestion, please provide it.

> Again, TLS or SSH do not prevent this sort of hacks.

Similar to the above statement, is there text around this that states
more than the 5-tuple is needed?  I would think the documentation of
what is used makes that clear already.  A 2-tuple would prevent this
type of monitoring, which is also a possibility and good to document
so application developers are aware of this usage and might discuss it
further with operators when considering a move to encrypted protection
that moves this from having the 5-tuple exposed to only having the
2-tuple exposed.  the prevalence and importance could be discussed at
that time, it's just important to have an understanding of use for the
purpose of this document.

> very good reason to deploy encryption.

Interesting.  Could you propose text written neutrally that documents
this application of compression?  I don't speak French.  This document
does not endorse the documented practices.  We had some statements
sprinkled throughout the document, but through reviews, it was
deciding framing text in the introduction was sufficient.

> It seems to me that RFC 1984 already replies to this reasoning.

The full text of that section is as follows:

   Mobile Networks and many ISPs operate under the regulations of their
   licensing government authority.  These regulations include Lawful
   Intercept, adherence to Codes of Practice on content filtering, and
   application of court order filters.  Such regulations assume network
   access to provide content filtering and accounting, as discussed
   below.

RFC1984 is already mentioned in the introduction in the same paragraph
that explicitly states the documented practices are not endorsed.  I
see why you might be concerned and we've tried to avoid repeating
these points throughout the document, but I'll propose text to see if
it is agreed upon (or a tweaked version):

NEW:

   Mobile Networks and many ISPs operate under the regulations of their
   licensing government authority.  These regulations include Lawful
   Intercept, adherence to Codes of Practice on content filtering, and
   application of court order filters.  Such regulations assume network
   access to provide content filtering and accounting, as discussed
   below.  As previously stated, the intent of this document is to document
   existing practices, the development of IETF protocols follows the
   guiding principles of [RFC1984] and [RFC2804].

It feels unnecessary and duplicative to me, but understanding if
others find this or a variant of this text useful would be helpful.

> endpoint, otherwise it is not a service, it is censorship.

I think that point is subjective and debatable.  While important, it
would be a rat hole.  In the interest of being productive, do you have
a text suggestion that keeps us out of that discussion and just
documents use of monitoring without endorsement?  Considering the
introductory text that already exists?  TIA.

> filtering proxy. No need to break encryption for that.

Hmm, I think we are reading the text differently as I read it as
describing this use usage that you seem to be okay with (this document
merely documents it, does not endorse it).  This still breaks e2e, but
in a way that is permitted by the end user who decides to trust this
service.  We were trying not to split hairs on methods used to view
traffic - it is already sent in the clear, some type of interception
is performed (enterprise use cases where the server is already managed
by that entity), or proxy services that serve as an endpoint for the
encrypted session.  Do you have text tweaks to suggest if you look at
this again and find a place where it is not written as intended?  I
don't seen an issue with the quoted text, but that could just be me.
TIA.

> and, if encryption stops it, great.

Omitting this text would be ignoring the practice.  Isn't it better to
document all uses of monitoring to understand motivations and to open
discussions between protocol developers and operators?  This may
result in wide-scale use of encryption to protect this data, but it
could also highlight to developers the need to communicate with end
users and find alternate methods to offer information to users.

I think MNOT may have commented on this same section, so perhaps he
has suggestions.  If not, text suggestions are welcome.

> A mention of RFC 6108 would be cool here.

That's a good addition.  I only skimmed, but it states a requirement
on port 80, so this relies on a clear text stream, is that right?
Do you have text to propose for this addition?

>> monitor incoming mail to remove SPAM

Thanks for catching that.

-- 

Best regards,
Kathleen

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Nov 2017 14:17:15 +0800

Hi,

> - Content compression (depending on how it's interposed)

Perhaps the devil is in the detail in each of these cases, but in
sorting through them there are probably authorized ways to accomplish
certain goals, while others might need to be left behind.  It seems like
in most of these cases it comes down to a matter of authorization, and
the relationship between parties.  I don't think that's for this
document to delve too deeply into, but as one decides which problems to
work on later, at that point, teasing out those aspects may be
worthwhile.  Starting with a statement of what the issues they are
facing are is pretty much factual.   Whether we choose to address those
issues over time is separate.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Tue, 14 Nov 2017 10:12:45 -0800

Hi Kathleen,
>adoption of encryption could suffer.

Thanks for that comment.

>statement that authenticated encryption is preferred?

Sorry for not being clear.  The draft states that "NULL 
Authentication with IPsec" has been implemented and deployed.  Given 
that it is a practice, is it a good idea?  That was my point.  The 
document is length as it is.  I don't think that adding more text 
would make it better.

Stepping back, I'd say that the authors should decide what the 
document is about.  Is it about documenting what is in use by 
operators?  Is it a discussion of the practices?  Is it about telling 
the reader what the IETF recommends?

>That could depend on the content of data exposed.  Are you suggesting

There was a news article in the Washington Post about such an 
issue.  From what I recall, it was considered as a security issue.  I 
suggest looking at this from a security perspective.

>debugging and logging capabilities.

The text which led me to the question is the second paragraph in 
Section 2.1.2.  The DPI specification (Y.2770) references RFC 3871; 
it's related to logging capabilities (please see the paragraph quoted 
above).  DPI is about inspecting the traffic (including content) 
passing through the network.  The primary function of the DPI device 
is not troubleshooting.  Nowadays, the function is supposed to be DLP.

Why does an encrypted stream prevent the the network from being 
excluded as "the problem"?  If I understood the arguments in that 
section, the IETF might as well recommend "cleartext" to make "the 
internet work better".

>you could clarify, I would appreciate it.

I don't understand why the document is discussing about 
spam.  Anyway, STARTTLS does not have any effect on spam 
filtering.  The sentence, as written, sounds like: in theory, 
STARTTLS has zero effect ...

The last paragraph in Section 3.2.2 gets into "user-to-user 
encryption" and provides a reference to a vendor.  What does that 
have to do with the heading for that section?

>documenting the impacts to serve as a start to that conversation.

I read RFC 7258 and the draft once again.

Regards,
S. Moonesamy

---

From: Adam Roach <[email-masked]>
Date: Wed, 15 Nov 2017 12:00:07 +0800

> issues over time is separate.

And the goalposts go shooting off into the distance.

Mark is right. The questionability of some of these practices in some of 
the ways they have been deployed argues against the use of the word 
"ideally".

/a

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Nov 2017 00:06:26 -0500 (EST)

On Tue, 14 Nov 2017, S Moonesamy wrote:

> Sorry for not being clear.  The draft states that "NULL Authentication with 
> IPsec" has been implemented and deployed.  Given that it is a practice, is it 
> a good idea?

The deployments I'm aware of with mesh encryption using IPsec did try
to keep some kind of network based monitoring/filtering in place, but
in the end concluded enterprise wide mesh encryption is more important,
and the rules of the network monitoring/firewalls can be pushed to the
endnodes using the usual sync methods (puppet, ansible, new gold image
container, etc).

I dont think the IETF should try to answer whether it is a good idea or
not. There was a need for this, and we enabled the protocol to perform
this optional function.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Nov 2017 14:14:43 +0800

On Wed, Nov 15, 2017 at 1:06 PM, Paul Wouters <[email-masked]> wrote:
>> Sorry for not being clear.  The draft states that "NULL Authentication
>> with IPsec" has been implemented and deployed.  Given that it is a practice,
>> is it a good idea?
>
>

... and the document isn't trying to make those sorts of judgement
calls. I've heard some mumblings that people thought that this
document was somehow recommending against encryption or that
encryption is "bad" in some way. This really isn't the intent; rather
documenting places where encryption impacts operators network
management practices informs the operator so they can design new ways
to manage the network, and also informs protocol designers so they are
aware that removing certain information may negatively impact how well
the network works (and so negatively impact their performance).

An example of this is that some enterprises prioritize VoIP / video
conference traffic (esp from remote offices) to provide better user
experience. Having this data encrypted (e.g from a browser) is (note:
personal judgement call here!) a good thing, but it does mean that the
enterprise cannot use their existing methods to prioritize the
traffic, and having them know this is useful - otherwise a: the
quality gets sucky, and b: the enterprise may try block this.
So, documenting the effects of encryption is NOT to discourage it, but
rather try make it better deployed -- the authors are not
anti-encryption, quite the opposite.  One of the authors is a Security
AD, the original sponsoring AD was another Security AD (Stephen).

Much of the document came from contributions - earlier versions of the
document hadn't fully scrubbed the tone to remove judgements - please
note that it has had significant rewrites to scrub this; places where
there may be implications that encryption is bad are not intentional
and should be point out so they can be addressed (e.g the "ideally")

W

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Nov 2017 03:22:37 -0500

Hi SM,

Thanks for your additional comments, inline.

On Tue, Nov 14, 2017 at 1:12 PM, S Moonesamy <[email-masked]> wrote:
> IPsec" has been implemented and deployed.  Given that it is a practice, is
> it a good idea?  That was my point.  The document is length as it is.  I
> don't think that adding more text would make it better.

We have tried not to comment on what's a good idea or not in the
document, so I'd rather not start. If you have read something that
sounds like we have, please let us know and we'll make sure to edit to
just document the practice.  Text is always welcome with such
suggestions.

>
> Stepping back, I'd say that the authors should decide what the document is
> about.  Is it about documenting what is in use by operators?  Is it a
> discussion of the practices?  Is it about telling the reader what the IETF
> recommends?

Just the first and that's stated in the document introduction and abstract.

> There was a news article in the Washington Post about such an issue.  From
> what I recall, it was considered as a security issue.  I suggest looking at
> this from a security perspective.

Fair point, deploying encryption assists with confidentiality and
integrity and isn't necessarily in regard to privacy.  Thanks for
highlighting this text.

NEW:
 "This and other increases in the use of encryption had the immediate
  effect of providing confidentiality and intergity for protected
data, but created a
  problem for some network management functions."

> The text which led me to the question is the second paragraph in Section
> 2.1.2.  The DPI specification (Y.2770) references RFC 3871; it's related to
> logging capabilities (please see the paragraph quoted above).  DPI is about
> inspecting the traffic (including content) passing through the network.  The
> primary function of the DPI device is not troubleshooting.  Nowadays, the
> function is supposed to be DLP.
>
> Why does an encrypted stream prevent the the network from being excluded as
> "the problem"?  If I understood the arguments in that section, the IETF
> might as well recommend "cleartext" to make "the internet work better".

We'll have to look at this a bit closer, thank you for pointing out
the section that led you to that conclusion.  We'll work on it.

> I don't understand why the document is discussing about spam.  Anyway,
> STARTTLS does not have any effect on spam filtering.  The sentence, as
> written, sounds like: in theory, STARTTLS has zero effect ...

This was requested by the sponsoring AD at the time in his review.  It
seemed like a reasonable addition to state that there is no impact in
this instance, so we added it.

>
> The last paragraph in Section 3.2.2 gets into "user-to-user encryption" and
> provides a reference to a vendor.  What does that have to do with the
> heading for that section?

Are you referring to DarkMail as a vendor?  It seems they are a
technical alliance and had presented at SAAG a few years back.
user-to-user encryption will impact any mail service and could make
them irrelevant depending on the parts of the message encrypted.
There have been discussions about encrypting the header of mail in
addition to the body.  This was in earlier versions of the draft, but
I think got cut.  Do you think additional text is needed here?

> I read RFC 7258 and the draft once again.

Thanks for taking the time to do that and for your review and comments.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Nov 2017 03:28:07 -0500

On Tue, Nov 14, 2017 at 11:00 PM, Adam Roach <[email-masked]> wrote:
> Mark is right. The questionability of some of these practices in some of the
> ways they have been deployed argues against the use of the word "ideally".

Thanks Mark for spotting this, we'll address it in the update.

-- 

Best regards,
Kathleen