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

[Kathleen Moriarty <[e-mail]>]

Hi Eric,

A quick update per the discussion on a TLS draft.

On Mon, Feb 19, 2018 at 3:11 PM, Kathleen Moriarty
<[e-mail]> wrote:
> Hi Eric,
>
> Thanks for your feedback, responses are inline.
>
> FYI - I posted another version, but expect at least one more iteration
> after this version with additional comments and the ones we haven't
> gotten to yet.
>
> On Thu, Feb 8, 2018 at 12:04 AM, Eric Rescorla <[e-mail]> wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-mm-wg-effect-encrypt-17: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I have completely re-reviewed the latest version. First, I want to
>> thank you for toning down some of the material that I was concerned
>> about.
>>
>> Unfortunately, the fundamental concern that motivated my DISCUSS
>> remains: I do not believe that this document matches the consensus
>> of the IETF community.
>>
>> Specifically, this document takes at face value a large number of
>> claims about the necessity/value of certain practices that either are
>> controversial within the IETF or that there is, I believe, rough
>> consensus to be actively bad, and that in many cases, encryption is
>> specifically designed to prevent. I have noted a number of these
>> below, but I do not believe that this is an exhaustive list (going
>> through my previous DISCUSS, I see that I noted a number of these but
>> that still appear to be unaddressed.)
>
> In the previous round of IESG reviews, the IESG concluded that framing
> upfront was the preferred approach to make it clear that not all cited
> practices are ones the IETF consider valid.  This was done in the
> updated introduction.
>
> Please respond to the discussion points as I believe your additional
> points have been addressed to also make these points again in the
> document.  In a couple of places, we have questions to make sure your
> concern is understood.
>
>>
>>
>> DISCUSS
>>    session encryption that deployed more easily instead of no
>>    encryption.
>>
>> I think I understand what you are saying here, but the term
>> "breakable" seems very unfortunate, especially in the context of this
>> document. The only such shift I am aware of that has received
>> acceptance in IETF is one from always requiring fully authenticated
>> encryption to allowing unauthenticated encryption, which you document
>> in the next paragraph. I recognize that there are other perspectives
>> (e.g., those in draft-rhrd) but those are pretty far from IETF
>> consenus. Accordingly, I think you should remove this sentence.
>
> Opportunistic security was well discussed, so that was likely top of
> mind for you when reading this draft. However there are other areas
> where the IETF decided breakable encryption was better than none in
> recent years.  Another adopted and published example is in the mail
> community.  Deprecating MD5 was deemed to be too hard because of
> support in a particular library.  We had lengthy discussions about
> this for RFC7627 (see sect 6.2) and related drafts, now published
> RFCs.
>
> This sentence had nothing to do with the drafts that are not WG drafts
> in the TLS WG, but real use cases of published RFCs where deprecated
> crypto is still accepted despite efforts to correct that in addition
> to the acceptance of the OS approach in multiple session encryption
> protocols.  The support tools and use cases don't always drive the
> best solution where we have strong crypto everywhere as you have also
> noted on recent draft reviews, now published RFCs.
>
>>
>>
>>    motivation outside of privacy and pervasive monitoring that are
>>    driving end-to-end encryption for these content providers.
>>
>> This section seems kind of confusing, at least as applied to
>> HTTP. There are three kinds of cache in HTTP:
>>
>> - Reverse proxy caches (the kind CDNs run)
>> - Explicit forward proxy caches
>> - "Transparent" intercepting caches
>>
>> The first of these move to HTTPS just fine and that's typically how
>> CDNs do it.  Explicit forward proxy caches are largely going away, but
>> part of the point of this kind of end-to-end encryption is to hide
>> data from those caches.
>
> Sure, that point was made in the draft and cleared up a little further
> from Benjamin K's review.  The business risk associated with not
> controlling your content was more explicitly stated for CDNs who have
> moved to an e2e approach.
>
> Here's the updated sentence:
>    The business risk of losing control of content is a motivation outside
>    of privacy and pervasive monitoring that are driving end-to-end
>    encryption for these content providers.
>
>> Transparent intercepting caches that 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.  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?
>
>>
>>    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."
>
>>
>>
>>    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."
>
> 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.
>
>>
>>
>>    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:
>
> 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.
>
>>
>> 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.
>
>>
>>
>> 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.
>
> 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.
>
>>
>>
>>     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).
>
>>
>>
>>    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."
>
>>
>>
>>    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.
>
>>
>>
>>    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?
>
>>
>>
>> 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.
>
>>
>> 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.
>
>>
>>
>> ----------------------------------------------------------------------
>> 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
>
> Thanks.
>>
>>    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"
>
> Done, thanks.
>>
>>    recommendations from these documents were were built upon for TLS 1.3
>>    to provide a more inherently secure end-to-end protocol.
>> "were were"
>
> Already fixed, thanks.
>>
>>    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.,"
>
> Fixed, 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?
>
>>
>>    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?
>
>>
>>    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.
>
> 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.
>
>>
>>    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.
>
> 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.
>
>>
>>    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.
>
>>
>>    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?
>
>>
>>    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.
>
>>
>>    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.
>
>>
>>    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.
>
>>
>>    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.
>
>
>>
>>    [DarkMail].  Of course, SPAM filtering will not be possible on
>>    encrypted content.
>> 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.
>
>>
>>    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"
>
> Already fixed, thanks.
>>
>>    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
>
> Fixed, thanks.
>>
>>    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.
>
>>
>>    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
>
> Fixed, 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.  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.

 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

>
>>
>>    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!
>
>
>>
>>    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.
>
> 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.
>
>>
>>    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.
>
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen



-- 

Best regards,
Kathleen