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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> wrote:
> Thanks for the updated draft. Some responses below.
>
>
> On Mon, Feb 19, 2018 at 12:11 PM, Kathleen Moriarty
> <[e-mail]> wrote:
>>
>>
>> >
>> > DISCUSS
>> >    session encryption that deployed more easily instead of no
>> >    encryption.
>> >
>> > I think I understand what you are saying here, but the term
>> > "breakable" seems very unfortunate, especially in the context of this
>> > document. The only such shift I am aware of that has received
>> > acceptance in IETF is one from always requiring fully authenticated
>> > encryption to allowing unauthenticated encryption, which you document
>> > in the next paragraph. I recognize that there are other perspectives
>> > (e.g., those in draft-rhrd) but those are pretty far from IETF
>> > consenus. Accordingly, I think you should remove this sentence.
>>
>> Opportunistic security was well discussed, so that was likely top of
>> mind for you when reading this draft. However there are other areas
>> where the IETF decided breakable encryption was better than none in
>> recent years.  Another adopted and published example is in the mail
>> community.  Deprecating MD5 was deemed to be too hard because of
>> support in a particular library.  We had lengthy discussions about
>> this for RFC7627 (see sect 6.2) and related drafts, now published
>> RFCs.
>
>
> I continue to think that the term "breakable" is very unfortunate here
> (and of course, MD5 isn't breakable "encryption").

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

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

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

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

I'm fine with this wording suggestion.

>>
>> >    motivation outside of privacy and pervasive monitoring that are
>> >    driving end-to-end encryption for these content providers.
>> >
>> > This section seems kind of confusing, at least as applied to
>> > HTTP. There are three kinds of cache in HTTP:
>> >
>> > - Reverse proxy caches (the kind CDNs run)
>> > - Explicit forward proxy caches
>> > - "Transparent" intercepting caches
>> >
>> > The first of these move to HTTPS just fine and that's typically how
>> > CDNs do it.  Explicit forward proxy caches are largely going away, but
>> > part of the point of this kind of end-to-end encryption is to hide
>> > data from those caches.
>>
>> Sure, that point was made in the draft and cleared up a little further
>> from Benjamin K's review.  The business risk associated with not
>> controlling your content was more explicitly stated for CDNs who have
>> moved to an e2e approach.
>>
>> Here's the updated sentence:
>>    The business risk of losing control of content is a motivation outside
>>    of privacy and pervasive monitoring that are driving end-to-end
>>    encryption for these content providers.
>
>
>>
>> > Transparent intercepting caches that the user
>> > didn't opt into are a bad thing, so having them go away is a positive.
>>
>> The text says authorized parties, so this is referring to caches where
>> there is an agreement in place for this usage.
>
>
> 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?
>

I made the following edit to clarify:

    and the service provider through an authorized agreement acting

>
>>
>>   CDN's that wish to
>> block this behavior have the option to require e2e.  That trend alone
>> may be enough to kill this type of service offering.  I don't see why
>> it shouldn't be mentioned in terms of it's current use.  What change
>> are you looking to see here?
>
>
> I see you added the following text
>
>    It should be noted that caching was first supported in [RFC1945] and
>    continued in the recent update of "Hypertext Transfer Protocol
>    (HTTP/1.1): Caching" in [RFC7234].
>
> I would rewrite this:
>
>    It should be noted that explicit caching was first supported in [RFC1945]
> and
>    continued in the recent update of "Hypertext Transfer Protocol
>    (HTTP/1.1): Caching" in [RFC7234]. Some operators also operate
>    transparent caches which neither the user nor the origin opt-in to.
>    The use of these caches is controversial within IETF and is generally
>    precluded by the use of HTTPS.
>

Sure, text added.  Thanks for providing it.

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

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

Text updated, thanks.

>
>>
>> This was one of the reasons why we felt it was important to keep
>> section 4 separate.
>>
>> >
>> >    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.
>>
>> 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.
>
>
> 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.

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.

>
>
>>
>> > You also need to cover the fact that these MITM are a threat to user
>> > 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.
>
> 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]

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.

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

Update accepted.
>
>
>> >    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.
>>
>> 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."
>
>
> Thanks. This is a large improvement.
>
>
>> >    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?
>>
>> 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.
>
>
> 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.
>
>

Measurably has been removed.

>>
>> >    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.
>>
>> 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?
>
>
> 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."
>
>
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.
>
>
>
>> > 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/
>>
>> 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.
>
>
> Fine. Thanks.
>
>>
>>
>> >
>> > 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.
>>
>> 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.
>
>
>>
>>
>> >    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.
>>
>> There is no normative content.  Are you asking because the lowercase
>> should was used?
>
>
> Yes.

There's no terminology document referenced from this draft.

>
>
>
>>
>> >    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.
>>
>> 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?
>
>
> The new text seems clear enough. Thanks.
>
>
>
>>
>> >    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.
>>
>> This reads to me as if these are transparent proxies, so I'll add that
>> 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?
>
>
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).
>
>>
>> >    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.
>>
>> 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?
>
>
> Upon another read, this seems OK.
>
>
>
>> >    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.
>>
>> 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.
>
>
> Thanks.
>
>
>>
>> >    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.
>>
>> 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.
>
>
> Thanks.
>
>
>>
>>
>> >
>> >    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.
>>
>> 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.
>> >
>> >    headers to accomplish the, sometimes considered controversial,
>> >    functions above.
>> > 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.
>
>
> Thanks.
>
>
>
>
>> >    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?
>>
>> 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.
>
>
> Is this mostly referring to passive datacenter encryption? If so, perhaps
> I can provide a reword.

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.

>
>
>> >    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.
>>
>> 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.
>
>
> Thanks.
>
>
>
>
>>
>> >    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.
>>
>> The only option here for this described usage is a proxy where the TLS
>> 1.3 session is terminated and restarted.
>
>
> Yep. That's basically true in TLS 1.2 as well.
>
>
>>
>>   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.
>
>
> 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.

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


Thanks,
Kathleen

>
>
>>
>> >    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,
>>
>> 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
>
>
>  This text looks good to me.
>
>
>
>
>>
>> >    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
>>
>> 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.
>
>
> 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
>
>>
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



-- 

Best regards,
Kathleen