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

From: Eric Rescorla <[email-masked]>
Date: Wed, 07 Feb 2018 21:04:34 -0800

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 anti-phishing platform (Safe Browsing) operates in the
client, not be network interception.

    The transport header encryption prevents trusted transit proxies.  It
   may be that the benefits of such proxies could be achieved by end to

You don't define a "trusted transit proxy" so I don't know what this
means, and whether they provide any benefit, but this certainly sounds
euphemistic. Generally, "trusted" is not an adjective we associate
with network proxies operated by third parties.

   In the best case scenario, engineers and other innovators would work
   to solve the problems at hand in new ways rather than prevent the use
   of encryption.  As stated in [RFC7258], "an appropriate balance
   (between network management and PM mitigations) will emerge over time
   as real instances of this tension are considered."

Much of the context of this debate is about whether operators not
being able to do the things in this document is a problem, and this
seems to presume the answer.

   This optimization at network edges measurably improves real-time
   transmission over long delay Internet paths or networks with large

Do you have a citation for this claim?

   Web proxies are sometimes used to filter traffic, allowing only
   access to well-known sites found to be legitimate and free of malware
   on last check by a proxy service company.  This type of restriction
   is usually not noticeable in a corporate setting as the typical
   corporate user does not access sites that are not well-known to these
   tools, but may be noticeable to those in research who are unable to
   access colleague's individual sites or new web sites that have not
   yet been screened.  In situations where new sites are required for
   access, they can typically be added after notification by the user or
   proxy log alerts and review.  Home mail account access may be blocked
   in corporate settings to prevent another vector for malware to enter
   as well as for intellectual property to leak out of the network.
   This method remains functional with increased use of encryption and
   may be more effective at preventing malware from entering the
   network.  Web proxy solutions monitor and potentially restrict access
   based on the destination URL or the DNS name.  A complete URL may be
   used in cases where access restrictions vary for content on a
   particular site or for the sites hosted on a particular server.

If you are filtering on URL and there is HTTPS involved, then you are
a MITM, and this is potentially noticeable to end-users. We encounter
this regularly when MITM proxies make mistakes in getting into our
trust anchor store.

Re: 0-rating.
   user.  This feature is impacted if encryption hides the details of
   the content domain from the network.

Well, maybe. Facebook's zero rating, for instance, is IP-based.
https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/

S 2.2.2.
The presentation here seems biased given that it does not acknowledge
that one of the reasons that ISPs do traffic class discrimination is
to prioritize favored rather than disfavored traffic, regardless of
user preferences. I don't believe that the IETF has taken a position
for net neutrality, but I'm also pretty sure we don't have consensus
against it.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   Pervasive Monitoring (PM) attacks on the privacy of Internet users is
   of serious concern to both the user and the operator communities.
are of serious concern

   Traditional network management, planning, security operations, and
   performance optimization have been developed in an Internet where a
   large majority of data traffic flows without encryption.  While
you have a plural/singular mismatch here.

   Authentication with IPsec [RFC7619] and there are a number of
   infrastructure use cases such as server to server encryption, where
   this mode is deployed.  While OS is helpful in reducing pervassive
Nit, no comma before "where"

   recommendations from these documents were were built upon for TLS 1.3
   to provide a more inherently secure end-to-end protocol.
"were were"

   to-user content encryption schemes, such as S/MIME and PGP for email
   and encryption (e.g.  Off-the-Record (OTR)) for XMPP are used by
   those interested to protect their data as it crosses intermediary
Not, "e.g.,"

   been impacted by increases in encrypted traffic.  Only methods
   keeping with the goal of balancing network management and PM
   mitigation in [RFC7258] should be considered in solution work
   resulting from this document.
I don't understand what the normative content of this was.

   upgrades before user experience declines.  For example, findings of
   loss and jitter in VoIP traffic can be a predictor of future customer
   dissatisfaction (supported by metadata from the RTP/RTCP protocol )
   [RFC3550], or increases in DNS response time can generally make
   interactive web browsing appear sluggish.  But to detect such
   problems, the application or service stream must first be
   distinguished from others.

This is a little hard to read, but generally this information is not
encrypted for SRTP/SRTCP.

   When using increased encryption, operators lose a source of data that
   may be used to debug user issues.  Because of this, application
   server operators using increased encryption might be called upon more
   frequently to assist with debugging and troubleshooting, and thus may
   want to consider what tools can be put in the hands of their clients
   or network operators.

This is phrased as hypothetical, but is there any actual data to
support this? We have a lot of experience now with encrypted voice and
video as well as Web. Do those providers report any increased level of requests.

   the new flow and would not be able to route it back to the original
   POP.

I'm having a little trouble understanding this paragraph. Why is this
about mobile operators? It seems like it's an issue for anyone who has
a service that might have mobile clients.

   effective at providing data offload when there is a network element
   close to the receiver that has access to see all the content.
This section is also confusing in that it fails to distinguish between proxies
of this type that the user opts into from transparent proxies that just do this
service without the user's consent. Part of the purpose of encryption is to
preclude that.

   created from the intercepting device to the client's destination,
   this is an opt-in strategy for the client.  Changes to TLSv1.3 do not
   impact this more invasive method of interception, where this has the
I don't understand the cite to TLS 1.3 here. None of this is presently affected
by 1.3.

   endpoints as a service reduces providers' ability to offer parental
   control.
This section makes it seem like there are no other methods that allow for
parental control, but that's not true. There are parental control mechanisms
which rely on MITM proxies or application interfacing.

   HTTP headers and content are encrypted, this prevents mobile carriers
   from intercepting the traffic and performing an HTTP redirect.  As a
   result, some mobile carriers block customer's encrypted requests,
Yes, stopping traffic redirection is actually one of the major design purposes
of HTTPS.

   to the customer and additional overhead to the mobile network service
   provider.
This section is basically a commercial for this practice. It needs to
acknowledge that it's actually much closer to IETF consensus that it's a bad
practice.

   headers to accomplish the, sometimes considered controversial,
   functions above.
Again, this is precisely the form of attack that HTTPS is intended to prevent.

   perform SSL/TLS decryption are impacted by the increased use of
   encryption that prevents interception.
I don't really understand what this text means. What is "use of encryption that
prevents interception" in the context of tools which already do decryption?

   [DarkMail].  Of course, SPAM filtering will not be possible on
   encrypted content.
This is not strictly correct, as you can still header filter, etc.

   over the Internet.  Options for monitoring will vary with each
   encryption approach described below.  In most cases, solution have
   been identified to provide encryption while ensuring management
Nit: "solutions have"

   allow for multiple end user sessions to share the same TCP
   connection.  This rasises several points of interest with an
   increased use of encryption.  TCP session multiplexing should still
Typos: rasises

   be possible when TLS or TCPcrypt is in use since the TCP header
   information is exposed leaving the 5-tuple accessible.  The use TCP
   session multiplexing of an IP layer encyption, e.g.  IPsec, that only
I'm not sure if this is correct. What precisely do you mean by "TCP
session multiplexing"? A cite would be helpful here.

   center.  HTTP pipelining requires both the client and server to
   participate; visibilty of packets once encrypted will hide the use of
   HTTP pipelining for any monitoring that takes place outside of the
Typo: visibility

   traffic cannot be intercepted, encouraging alternate options such as
   performing these functions at the edge.
I'm not seeing the relevance of this. Who is proposing solutions in which
encrypted traffic cannot be intercepted at the outgoing network edge.

   owing to concealment of critical headers and payloads.  Many forms of
   enterprise performance management may be similarly affected.
Again, this is sort of transparent caching is an anti-pattern, so this document
ought to acknowledge that,

   parts of the address assignment/management protocols, critical for
   SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms.
Does anyone actually deploy SAVI? If not, encryption isn't having much of an
impact.

   network filters look out for seeing a Server Name Indication
   extension, they may not find one.  The SNI Encryption in TLS Through
   Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the
This doesn't really follow. I mean they "may not" but overwhelmingly they will

---

From: Eliot Lear <[email-masked]>
Date: Thu, 8 Feb 2018 10:02:34 +0100

Hi EKR,

> S 5.4.
(I think you mean S 5.3, but this equally applies to section 5.5, so...)
> 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.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 8 Feb 2018 10:19:38 +0100

> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/
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

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Feb 2018 19:17:14 +0900

> If the process has not been followed, this requires facts as opposed
> to "believes".

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 8 Feb 2018 15:01:52 +0100

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 <[email-masked]>:
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 8 Feb 2018 11:53:55 -0900

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 8 Feb 2018 21:59:20 +0100

On 08.02.18 21:53, Melinda Shore wrote:
> 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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 9 Feb 2018 02:08:32 +0000

> On Feb 8, 2018, at 5:17 AM, Randy Bush <[email-masked]> wrote:
> 

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

Or a DDoS against the ideas on this document?

> randy

—
Carlos Pignataro, [email-masked]

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

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 8 Feb 2018 21:40:53 -0500

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Feb 2018 16:18:42 +0900

> presumably there would ahve been significant dissent during the IETF

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 19 Feb 2018 15:11:49 -0500

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.

> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

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.

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

> 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

The text says authorized parties, so this is referring to caches where
there is an agreement in place for this usage.  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?

> not just to cite the RFCs.

We can add the following (or suggest something else):

"and explicitly do not support tools and methods that could be used
for wiretapping and censorship."

> providing broader unfiltered access."

I've added the following to the end of the sentence as the RFC is too
long to repeat what is already in 7754:

   "and the IAB consensus on those mechanisms."

But I'll note that this cherry picks one part of the conclusion
section of 7754 and even this text acknowledges that some network
filtering is needed in the suggested hybrid approach.

The first paragraph of this section says:
  "Filtering will continue to occur on the Internet. We conclude that,
   whenever possible, filtering should be done on the endpoint.
   Cooperative endpoints are most likely to have sufficient contextual
   knowledge to effectively target blocking; hence, such blocking
   minimizes unintended consequences.  It is realistic to expect that at
   times filtering will not be done on the endpoints.  In these cases,
   promptly informing the endpoint that blocking has occurred provides
   necessary transparency to redress any errors, particularly as they
   relate to any collateral damage introduced by errant filters."

This text does not say it is bad, it says that it should occur when
possible on the endpoint and that in cases where it is not possible,
the end points should be notified of this filtering.  That's different
from saying filtering is bad as there are a number of cases why the
IAB agreed on a hybrid approach.

DDoS mitigation requires the use of SP filtering to be effective.
This is a clear example of where filtering must be done on the network
and is very important and hard to argue that it isn't good.  You may
have to step back toward the source of the traffic, iteratively
setting up filters to block traffic through cooperation of SPs until
you get close to the source.

Filtering recommended in BCP38 certainly has had a positive impact.

SPs also use filtering to protect their own infrastructure.

This was just a quick response, I am sure there are other good
examples that supported the hybrid recommendation.

> it's also a form of user surveillance.

This is referring to corporate networks.  The rules are a bit
different since you get a paycheck and agree to monitoring, sign an
acknowledgement as an employee then operate on their equipment and
network.

To help make this point more clear, I've added text into section 4.1,
let us know if this does not address your concern:

OLD:
Large corporate enterprises are the owners of the platforms, data, and
network infrastructure that provide critical business services to
their user communities. As such, these enterprises are responsible for
all aspects of the performance, availability, security, and quality of
experience for all user sessions. These responsibilities break down
into three basic areas:

NEW:
Large corporate enterprises are the owners of the platforms, data, and
network infrastructure that provide critical business services to
their user communities. As such, these enterprises are responsible for
all aspects of the performance, availability, security, and quality of
experience for all user sessions. Users typically sign agreements
acknowledging that they are subject to monitoring while operating on
corporate networks. Subsections of 4. Encryption for Enterprises may
discuss techniques that access data beyond the data-link, network, and
transport level headers typically used in SP networks since the
corporate enterprise owns the data. These responsibilities break down
into three basic areas:

This was one of the reasons why we felt it was important to keep
section 4 separate.

> As far as I know, the MITM techniques used by middleboxes are not

The use of an RSA static key is discussed in terms of the danger of
using this approach in Section 2.8. I updated the text slightly to
make this point more clear and added the section reference:

Various techniques are used to intercept HTTP/TLS sessions for DLP and
other purposes, and can be misused as described in "Summarizing Known
Attacks on TLS and DTLS [RFC7457] Section 2.8.

> security because they are often so badly implemented.

I think 7457 does a good job of that.  Let us know if you have
proposed text if the above fix isn't enough for you coupled with this
being in the Enterprise section.

> client, not be network interception.

We responded on this previously pointing out that this is mentioned in
section 5.3 on phishing.  Here's the text:

   Administrators might also add URLs contained in
   messages to block lists locally or this may also be done by browser
   vendors through larger scales efforts like that of the Anti-Phishing
   Working Group (APWG).  See the Coordinating Attack Response at
   Internet Scale (CARIS) workshop Report [RFC8073] for additional
   information and pointers to the APWG's efforts on anti- phishing.

The CARIS report goes a bit deeper as well.  The approach is broader
than just the browser vendors and that should be acknowledged.
Cooperation of many other players is involved in updating the block
lists and working with law enforcement to take down the offending
sites.  Safe Browsing is just one piece of the larger puzzle and the
browser block lists are already mentioned.

> with network proxies operated by third parties.

We added a little more text on this per Benjamin's comment.  I'm
including the full text of the paragraph so this is not taken out of
context as endorsing such mechanisms as the text goes on to say other
ways it could be addressed in an encrypted Internet.  Here is the
text.

     Transport header encryption prevents the use of transit proxies
     in center of the network and the use of some edge proxies by preventing
     the proxies from taking action on the stream. It may be that the benefits
     of such proxies could be achieved by end-to-end client and server
     optimizations, distribution using CDNs, plus the ability to continue
     connections across different access technologies (across dynamic
     user IP addresses).

> seems to presume the answer.

Section 8 has been overhauled in response to Deborah's comments. I see
what you mean in the wording and that was not intended. The goal of
the draft is to help improve adoption by talking about the issues and
bringing them to the surface for discussion (tough discussions that
need to happen).  Here is the current text.

"As stated in [RFC7258] an appropriate balance (between network
management and PM mitigations) will emerge over time as real instances
of this tension are considered." Numerous operators made it clear in
their response to this document that they fully support strong
encryption and providing privacy for end users, this is a common goal.
Operators recognize not all the practices documented need to be
supported going forward, either because of the risk to end user
privacy or alternate technologies and tools have already emerged. This
document is intended to support network engineers and other innovators
to work toward solving network and security management problems with
protocol designers and application developers in new ways that
facilitate adoption of strong encryption rather than preventing the
use of encryption. By having the discussions on network and security
management practices with application developers and protocol
designers, each side of the debate can understand each others goals,
work toward alternate solutions, and disband with practices that
should no longer be supported. A goal of this document is to assist
the IETF to understand some of the current practices so as to identify
new work items for IETF-related use cases which can help facilitate
the adoption of strong session encryption and support network and
security management."

> Do you have a citation for this claim?

The draft that this text refers to in the previous paragraph has a
section on performance enhancing proxies, section 3.5 and is referred
to right before this text. David Dolson was the contributor.

> this regularly when MITM proxies make mistakes in getting into our

This is in the enterprise section where monitoring is accepted by end
users.  What is your proposal here?  I don't see an issue with
describing this usage.  Are you okay with this text since you also see
this as an issue and perhaps it needs more discussion?

> https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/

It seems the providers or applications offering 0-rating all operate
differently.
https://arstechnica.com/information-technology/2016/02/verizons-mobile-video-wont-count-against-data-caps-but-netflix-will/

I had more of an issue with the word feature here, so I believe I
addressed your comment and my concern with the following:

     For some implementations, zero rating is impacted if encryption
     hides the details of the content domain from the network.

> for net neutrality, but I'm also pretty sure we don't have consensus

How about the following text:
This section does not consider traffic discrimination by service
providers related to NetNeutrality, where traffic may be favored
according to the service provider preference as opposed to the user's
preference. These use cases are considered out-of-scope for this
document as controversial practices.

Thanks.
> Nit, no comma before "where"

Done, thanks.
>    to provide a more inherently secure end-to-end protocol.

Already fixed, thanks.
>    those interested to protect their data as it crosses intermediary

Fixed, thanks.
> I don't understand what the normative content of this was.

There is no normative content.  Are you asking because the lowercase
should was used?

> encrypted for SRTP/SRTCP.

In looking at the text, the Secure version of RTP/RTCP isn't mentioned
and isn't cited as an issue.  The text (from Dave Dolson, we think)
seems to say that any form of security that obscures the application
or service info of the stream complicates analysis as VoIP, or
analysis as <something else>.

If this isn't clear enough, would you like to propose text?

> video as well as Web. Do those providers report any increased level of requests.

This makes perfect sense.  If you are troubleshooting and the data is
not available at the endpoint, the network is used.  If that goes
away, logging and reporting at the endpoint has to improve.  If you
take a look at the feedback from the OPsDir review, it had several
specific types of log improvements added into a paragraph early into
the document.  I added a few more to that from other comments.

In my operational experience as well as work with customers at EMC,
I've heard this comment as well and it was addressed.  This is part of
why the increase in encryption with storage platforms is not a big hit
- tools were provided at the endpoint to fill the gap.

> a service that might have mobile clients.

If you mean laptops/IP based devices on WiFi access, this works
differently at the routing layer than with cellular mobile phones.
Phones need to be able to transition seamlessly with migrations
(coordinated roaming).  Other devices, like laptops on WiFi access,
might need this type of transition within a wireless managed
environment, but this is with APs that don't typically attempt to
preserve connection state. When IP based devices on WiFi access have
traffic traversing POPs, it's at the IP layer and the applications
handle continuity.  The key difference between WiFi and cellular is
maintaining connection state.

> service without the user's consent. Part of the purpose of encryption is to

This reads to me as if these are transparent proxies, so I'll add that
in to clarify the text further.  Thanks.

> I don't understand the cite to TLS 1.3 here. None of this is presently affected

This is saying that changes to TLSv1.3 do not impact this more
invasive method of interception explicitly, so I believe the text
already addresses your point.  If not, could you please suggest text?

> which rely on MITM proxies or application interfacing.

The section NOW starts off with the following in the first paragraph
that should address your concern:

    This section is intended to document a selection of current
    content blocking practices...

I think this came from Benjamin's review - the section is not
exhaustive (neither is the draft as it was contribution driven).

This text in the first paragraph should also help with your point:
    Content blocking may also happen at endpoints or at the edge
    of enterprise networks, but those are not addressed in this section.

At the edge is a proxy/gateway MiTM solution.

The next paragraph talks about proxies in the core or edge of a
network, these are also MiTM devices, so I think that's well covered.

The following sentence in this section calls this out as MiTM behavior
explicitly:

    Changes to TLSv1.3 do not impact this more invasive method of
     interception, that has the potential to expose every HTTPS
     session to an active man in the middle (MitM).

I ammended the following sentence in the last paragraph in case that helps you:

OLD:
This type of granular filtering could occur at the endpoint.

NEW:
This type of granular filtering could occur at the endpoint or as a
proxy service.

> Yes, stopping traffic redirection is actually one of the major design purposes

Sure, there's not an issue other than the practice needs to change and
they need to figure out better ways to notify customers.  It's raised
here in case better ideas can be developed and some operator may look
at the reference (RFC6108).  Adam and Al were chatting on this as a
result of his review, so hopefully they make a little progress.

I added the word appropriately as I think that will address your
concern.  The operators just want efficient ways to notify their
customers, it doesn't have to be done this way, but they raised the
issue because they don't know what to do and I believe, want help.

NEW:
When the HTTP headers and content are encrypted, this appropriately
prevents mobile carriers from intercepting the traffic and performing
an HTTP redirect.

> acknowledge that it's actually much closer to IETF consensus that it's a bad

This text was already changed as follows:

     The customer may need to call customer care to find out the
     reason and/or resolve the issue, possibly extending the time
     needed to restore their network access.
> Again, this is precisely the form of attack that HTTPS is intended to prevent.

The following paragraph was added per conversations with Christian and
Martin.  Hopefully, this also addreses your concern.  The paragraph
mentioned was amended as well.

NEW:
    Guidance from the Internet Architecture Board has been provided
     in [RFC8165] on Design Considerations for Metadata Insertion.
     The guidance asserts that designs that share metadata only by
     explicit actions at the host are preferable to designs in which
     middleboxes insert metadata. Alternate notification methods that
     follow this and other guidance would be helpful to mobile carriers.

> prevents interception" in the context of tools which already do decryption?

This reads clear enough to me, but would you be happier with:

s/impacted/no longer functions/

It's referring to encryption that prevents interception, not talking
about proxies which still can be used technically.  This change has
not been made yet, so please let us know if this helps or if you have
another suggestion.

> This is not strictly correct, as you can still header filter, etc.

It seems a few words were trimmed in what you have quoted above.
Here's the full sentence:

Of course, content-based spam filtering will not be possible on
encrypted content.

I'm not sure what happened there as I don't think this was a recent
fix. The sentence was in context of content-based filtering.

In much earlier versions of this draft, there was mention of efforts
that would encrypt email header information to protect privacy
discussed a couple of years ago (SAAG and a spin off list) - which is
a good thing to do.  If that happens operations are impacted and that
would require discussion to develop new approaches for spam filtering
and other email based attack prevention techniques.

>    been identified to provide encryption while ensuring management

Already fixed, thanks.
>    increased use of encryption.  TCP session multiplexing should still

Fixed, thanks.
> session multiplexing"? A cite would be helpful here.

It's described in section 4.1.3.2:

    TCP pipelining/session multiplexing used mainly by
    middleboxes today allows for multiple end user sessions
    to share the same TCP connection.

>    HTTP pipelining for any monitoring that takes place outside of the

Fixed, thanks.
> encrypted traffic cannot be intercepted at the outgoing network edge.

The only option here for this described usage is a proxy where the TLS
1.3 session is terminated and restarted.  If you look back to slides
from Stephen on PM and advancements resulting from PM being considered
an attack, one of the ideas to make TLS stronger was DANE
authentication to provide a way to know you truly have an e2e session
- a very good thing.  The draft on the last telechat:
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/
that should be approved soon is able to do this with some middleboxes,
but I'm not sure what happens with a proxy - so I asked the editors
for clarification.  If this just doesn't work and the session proceeds
without this extension, there is nothing to notify on.  If this is
something proxies should be aware of to allow through unhampered, it
would be good to include a little more text.  For instance, in
corporate networks certain traffic with PII, like financial
transactions, are not proxied and would benefit from using this
extension, giving their users assurance in the security of their
sessions.

> ought to acknowledge that,

I added the following text at the end of this paragraph to address your concern:
It should be noted that transparent caching is considered an anti-pattern.

If you have alternate text to suggest, please do!

> Does anyone actually deploy SAVI? If not, encryption isn't having much of an

It appears to be the case with drafts being published as recent as 2017:
https://tools.ietf.org/html/rfc8074

And I'm told it is widely deployed in China.

> This doesn't really follow. I mean they "may not" but overwhelmingly they will

I'm not sure when the text was changed, but it already has been changed from.

OLD:

   This information is only visible if the client is populating the
   Server Name Indication extension.  This need not be done, but may be
   done as per TLS standard and as stated above this has been
   implemented by all major browsers.  Therefore, even if existing
   network filters look out for seeing a Server Name Indication
   extension, they may not find one.

NEW:
This information is only available if the client populates the Server
Name Indication extension. Doing so is an optional part of the TLS
standard and as stated above this has been implemented by all major
browsers. Due to its optional nature, though, existing network filters
that examine a TLS ClientHello for a SNI extension cannot expect to
always find one.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 22 Feb 2018 14:27:40 -0500

Hi Eric,

A quick update per the discussion on a TLS draft.

> extension, giving their users assurance in the security of their

 In some cases, alternate options are available when encryption is in
use through a proxy or a shift to monitoring at the endpoint. In both
cases, scaling is a concern and advancements to support this shift in
monitoring practices will assist the deployment of end-to-end
encryption.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Feb 2018 10:22:13 -0800

Thanks for the updated draft. Some responses below.

> this for RFC7627 (see sect 6.2) and related drafts, now published

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"

> 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

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.

Thanks.

Thanks.

> corporate enterprise owns the data. These responsibilities break down

To be honest, this revision seems more like it's endorsing this practice.
What
I'm looking for is an acknowledgement that this isn't really something
employees
want, but is forced upon them by the enterprise.

To take your text as a starting point, I propose:

"In many such enterprises, users are required to consent to the enterprise
monitoring all their activities as a condition of employment".

> Attacks on TLS and DTLS [RFC7457] Section 2.8.

Section 2.8 explicitly is about passive attacks, but MITM boxes are active,
so I don't think that 7457, while a valuable document, covers this.

> being in the Enterprise section.

Yeah, I still think this is missing something. Proposed new text:

The text I would propose here is:
"Aside from exposing user information to the enterprise MITM devices often
are subject to severe security defects which can lead to exposure of user
data to attackers outside the enterprise [0]. In addition, implementation
errors in middleboxes have lead to major difficulties in deploying new
versions of security protocols such as TLS [Ben17a][Ben17b][Res17a][Res17b]

[0] @inproceedings{Bursztein2017TheSecuri, title={The Security Impact of
HTTPS Interception},author={Durumeric, Zakir and Ma, Zane and Springall,
Drew and Barnes, Richard and Sullivan, Nick and Bursztein, Elie and Bailey,
Michael and Halderman, J Alex and Paxson, Vern},booktitle={Network and
Distributed Systems Symposium},year={2017},organization={Internet Society}}

   [Ben17a]   Benjamin, D., "Presentation before the TLS WG at IETF
              100", 2017,
              <https://datatracker.ietf.org/meeting/100/materials/
              slides-100-tls-sessa-tls13/>.

   [Ben17b]   Benjamin, D., "Additional TLS 1.3 results from Chrome",
              2017, <https://www.ietf.org/mail-archive/web/tls/current/
              msg25168.html>.

    [Res17a]   Rescorla, E., "Preliminary data on Firefox TLS 1.3
              Middlebox experiment", 2017, <https://www.ietf.org/mail-
              archive/web/tls/current/msg25091.html>.

   [Res17b]   Rescorla, E., "More compatibility measurement results",
              2017, <https://www.ietf.org/mail-archive/web/tls/current/
              msg25179.html>.

>      connections across different access technologies (across dynamic

This text assumes that there are such benefits, but that's a point of
contention. I would be fine if you put "claimed" in front of "benefits"

> the adoption of strong session encryption and support network and

Thanks. This is a large improvement.

> to right before this text. David Dolson was the contributor.

Yes. Unfortunately that document itself provides no data to support its
claims,
so they need to be regarded as speculative, and certainly not have the
word "measurably" attached to them, absent a citation.

> this as an issue and perhaps it needs more discussion?

My objection is just to the claim "usually not noticeable". I would be fine
with "This type of restriction is intended to be transparent to users in a
corporate setting as the typical corporate user does not access sites
which are not well-known to these tools. However, the mechanisms
which these proxies use to do monitoring and enforcement have the
potential to cause large-scale breakage or other user-visible failures."

> https://arstechnica.com/information-technology/2016/
> 02/verizons-mobile-video-wont-count-against-data-caps-but-netflix-will/
>

Fine. Thanks.

Thanks.

> There is no normative content.  Are you asking because the lowercase

Yes.

> If this isn't clear enough, would you like to propose text?

The new text seems clear enough. Thanks.

> in to clarify the text further.  Thanks.

This ended up kind of confusing, at least to me:

   The primary method is
   for the mobile application to connect to a centralized server as a
   transparent proxy (user does not opt-in), with the data channel
   between the client application and the server using compression to
   minimize bandwidth utilization.  The effectiveness of such systems
   depends on the server having access to unencrypted data flows.

My understanding is that there are two major ways to do compression
for endpoints:

1. Single-ended (where you just compress the data, often by degrading
the user's experience, as by downscaling), but it's ultimately compatible
with the client.
2. Double-ended (where you modify both the endpoint and the proxy)
and then do some incompatible form of compression (e.g., transcoding
or doing a non-widely supported compression mechanism).

Which one of these are you referring to?

> already addresses your point.  If not, could you please suggest text?

Upon another read, this seems OK.

Thanks.

Thanks.

Thanks.

> not been made yet, so please let us know if this helps or if you have

Is this mostly referring to passive datacenter encryption? If so, perhaps
I can provide a reword.

Thanks.

> 1.3 session is terminated and restarted.

Yep. That's basically true in TLS 1.2 as well.

>   If you look back to slides

Thanks for the explanation. I think this gets to an important point: it's
true that
there are a variety of protocol mechanisms which one could put in place
which
would block MITM proxies. However, we could *already* do that because the
clients are often aware in many cases of when MITM proxies are in use
(because the certs are pinned). However, they still let those connections
go through because the users would be very sad if they couldn't get
to Facebook. So I would anticipate the same dynamic here.

> If you have alternate text to suggest, please do

 This text looks good to me.

> that examine a TLS ClientHello for a SNI extension cannot expect to

I continue to believe that this doesn't accurately represent the situation.
Yes, it's technically true that you can't 100% count on it, but you almost
always get it, so much so that an enterprise could just block anyone
who doesn't provide SNI. o

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 26 Feb 2018 14:03:16 -0600

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 26 Feb 2018 21:15:15 +0100

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 26 Feb 2018 14:28:23 -0600

Hi, Benoit,

> 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

> OPSAWG mailing [email-masked]://www.ietf.org/mailman/listinfo/opsawg
>
>
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Feb 2018 16:15:54 -0500

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

>> scribe or as an IESG member), so maybe I don't get it, and other people have
>> different expectations.
>>
>> Spencer
>>
>>

-- 
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: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 26 Feb 2018 17:22:43 -0600

And, to be clear on one point ...

On Mon, Feb 26, 2018 at 3:15 PM, Warren Kumari <[email-masked]> wrote:

> folded in -

That's what I think, too, although I'm not the guy who gets to decide. I
wasn't questioning any of EKR's comments.

I just seek clue.

Spencer

> if we do have to ballot, I'd *think* that we are balloting
> IESG

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Feb 2018 14:23:44 -0500

> vote can change after we read it, so I should be tracking the proposed text

[ 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

Indeed.
W

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Feb 2018 06:16:42 -0800

> Approved, Revised ID needed / AD follow-up flag.

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

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Feb 2018 06:45:08 -0800

> Approved, Revised ID needed / AD follow-up flag.

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 28 Feb 2018 11:00:22 -0500

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 <[email-masked]> wrote:
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Feb 2018 08:49:30 -0800

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

-Ekr

On Wed, Feb 28, 2018 at 8:00 AM, Kathleen Moriarty <
[email-masked]> wrote:

>> 0

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Feb 2018 12:06:18 -0500

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Feb 2018 09:07:38 -0800

Thank you.

-Ekr

On Wed, Feb 28, 2018 at 9:06 AM, Warren Kumari <[email-masked]> wrote:

> >> Sorry, I wasn’t able to task switch to editing the document yesterday
> with
> >> other work obligations.
> >>
> >> Best,
> >> Kathleen
> >>
> >>> > vote can change after we read it, so I should be tracking the
> proposed
> >>> > text
> >>> > changes.
> >>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 28 Feb 2018 22:04:35 -0500

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 <[email-masked]> wrote:
> On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty

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.

> 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

I'm fine with this wording suggestion.

> network operator and the user. Who did you have in mind?

I made the following edit to clarify:

    and the service provider through an authorized agreement acting

>    It should be noted that explicit caching was first supported in [RFC1945]
> and

Sure, text added.  Thanks for providing it.

s/opt-in to./opt-in./

> monitoring all their activities as a condition of employment".

Text updated, thanks.

> so I don't think that 7457, while a valuable document, covers this.

Not all enterprise MiTM boxes are active, the ones cited by the
enterprise folks talking on the TLS list are not modifying traffic,
but just allowing for inspection.  They are viewing the traffic for
troubleshooting after the fact with captured traffic for instance,
which does not involve modification/active attacks.

> versions of security protocols such as TLS [Ben17a][Ben17b][Res17a][Res17b]

Including the text
s/lead/led/

I may leave out the email references as the presentation covers the
point and is a slightly better reference than an email.  The RFC
editor would likely cut them anyway.

>    [Ben17a]   Benjamin, D., "Presentation before the TLS WG at IETF

Update accepted.
> word "measurably" attached to them, absent a citation.

Measurably has been removed.

> potential to cause large-scale breakage or other user-visible failures."
For the large-scale breakage, are you referring to actual proxies that
terminate and restart the HTTS session?  With your example, it sounds
like that is the case.  This is just scanning the traffic for URL or
DNS to make decisions and doesn't terminate and restart the HTTPS
session.  If that's the case, I changed the first couple of sentences
to make this more clear as this is really just an enterprise level
product, so I don't think large-scale is an appropriate term here as
it's easy to override in the tool when needed.

I changed web proxy to web filtering devices and the last sentence
already explained that the URL and DNS were used for the filtering
determination.

NEW:
Web filtering devices are sometimes used to allow only access to
well-known sites found to be legitimate and free of malware on last
check by a web filtering service company. One common example of web
filtering in a corporate environment is blocking access to sites that
are not well-known to these tools for the purpose of blocking malware;
this may be noticeable to those in research who are unable to access
colleague's individual sites or new web sites that have not yet been
screened. In situations where new sites are required for access, they
can typically be added after notification by the user or log alerts
and review. Home mail account access may be blocked in corporate
settings to prevent another vector for malware to enter as well as for
intellectual property to leak out of the network. This method remains
functional with increased use of encryption and may be 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 monitor and potentially
restrict access based on the destination URL when available, server
name, IP address, or the DNS name. A complete URL may be used in cases
where access restrictions vary for content on a particular site or for
the sites hosted on a particular server. In some cases, the enterprise
may use a proxy to access this additional information based on their
policy. This type of restriction is intended to be transparent to
users in a corporate setting as the typical corporate user does not
access sites which are not well-known to these tools. However, the
mechanisms which these web filters use to do monitoring and
enforcement have the potential to cause access issues or other
user-visible failures.
>> There is no normative content.  Are you asking because the lowercase

There's no terminology document referenced from this draft.

> Which one of these are you referring to?
Al beleives it is #1

however, it does not "degrade the user's experience" to
decode a 4K video stream and re-encode as a lower resolution
format when the user is watching on a mobile phone at a
viewing distance of 9 picture-heights or more.

Also, the compression could be loss-less for data streams,
but that's a type 2 where both sides are equipped,
and the sentence talks about
transparent proxies with no opt-in.

Al would say:

Single-ended (where the proxy uses reduces transmission rate
by reducing the video format for mobile phone display sizes,
producing a stream that is compatible with the client).
> Is this mostly referring to passive datacenter encryption? If so, perhaps

Yes, I believe that is the case.  How about:
The use of passive tools that perform SSL/TLS decryption are impacted
by the increased use of encryption that prevents monitoring via
interception, while providing forward secrecy.

> to Facebook. So I would anticipate the same dynamic here.

Are you okay with current text or do you have proposed changes?

Thanks,
Kathleen

-- 

Best regards,
Kathleen