Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Hi Ben and Kathleen, on References: ... ... > >>> > >>> -12: Are there really no normative references? The definition of a > >>> "normative > >>> reference" is any reference needed to fully implement or _understand_ the > >>> document. This is true for both informational and standards-track > >>> documents. Do > >>> you think a reader can fully understand this document if they ignore every > >>> reference? (I'm willing to accept that the answer might be "yes" given > >>> the > >>> nature of this draft--but that situation is rare in practice.) > >> > >> We'll think about this a bit more, thanks. > >>> > >>> > > > > To be clear, I’m perfectly happy if you decide that there really are > no normative references; I just wanted to make sure it was thought > about. > > OK, Al and I need to chat about this one still. > [ACM] I gave this some thought, here's where I ended-up: * The references certainly help with understanding, but none are *unique* sources of background information that the reader should consult, if necessary. The necessary background can be derived from many sources. * There's no Normative text in the Informational Draft, so having Normative References doesn't seem a good match, to me. Al ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Hi Ben, Thanks for checking back through the responses. inline On Tue, Feb 13, 2018 at 2:35 PM, Ben Campbell wrote: > Hi Kathleen, > > Thanks for your response. Comments inline; I deleted sections that do not > seem to need further discussion. > > Thanks! > > Ben. > >> On Feb 9, 2018, at 1:18 PM, Kathleen Moriarty >> wrote: >> >> Hi Ben, >> >> Thanks again for the comments, responses and proposals are inline. >> >> On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell wrote: >>> Ben Campbell has entered the following ballot position for >>> draft-mm-wg-effect-encrypt-17: No Objection >>> >>> 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/ >>> >>> >>> >>> -- >>> COMMENT: >>> -- >>> >>> This is a considerably better document than the previous versions I have >>> reviewed. Thanks for all that work. But of course, I still have some >>> comments >>> :-) >>> >>> Substantive Comments: >>> >>> -2.2.2, 2nd paragraph: "... for example, many >>> forms of communications (from isochronous/real-time to bulk/elastic >>> file transfer) will take place over HTTP port 80 or port 443, so only >>> the messages and higher-layer data will make application >>> differentiation possible." >>> >>> I'm confused about the use of port 443 in that sentence; presumably traffic >>> to >>> 443 will be encrypted and not allow differentiation using higher-layer data. >> >> TLS 1.2 does leave data exposed for differentiation, SNI for example. >> TLS 1.3 leaves some, but there will be options to encrypt SNI at some >> point in the future. The response to ALPN will be returned in >> encrypted extensions in TLS 1.3. These are just the examples that >> come readily to mind and are included in the document. >> >> Do you think additional text is needed in this section around the port >> 443 example or is this covered enough later in the document? > > No, I think that's fine. I was not thinking about information revealed by TLS > itself. Thanks for confirming. > >> >> >>> >>> -2.2.4: This section lacks a discussion of the impact of encryption. >> >> Good point. I added one sentence at the edn of the second to last >> paragraph and modified the last paragraph as follows. Let me know if >> this looks good or you would like to see changes. >> >> If impacted by encryption, performance enhancing proxies could make >> use of routing >> overlay protocols to accomplish the same task, but this results in >> additional overhead. >> >> An application-type-aware network edge (middlebox) can further >> control pacing, limit >> simultaneous HD videos, or prioritize active videos against new videos, >> etc. >> Services at this more granular level are limited with the use of >> encryption. > > WFM. > >> >>> >>> -2.2.5, last paragraph: I understand that techniques that require endpoint >>> cooperation might be out of scope, but the tone of this paragraph makes it >>> sound like requiring endpoint cooperation is a negative. Is that the intent? >> >> Good catch, no that was not the intent and is in conflict with the >> following sentence. How about the following modification: >> >>Alternate approaches are in the early phase of being explored to >> allow caching of >>encrypted content. These solutions require cooperation from >> content owners and >>fall outside the scope of what is covered in this document. >> Content delegation >>allows for replication with possible benefits, but any form of >> delegation has the >>potential to affect the expectation of client-server confidentiality. > > WFM. > > […] > >>> >>> -2.3.1: I think it might be worth mentioning that an "intercepting >>> certificate" >>> requires endpoints to be configured to trust that certificate. (I assume we >>> are >>> not talking about the more unsavory practice of certificates that >>> misrepresent >>> their subjects. >> >> OK, I read this as being covered, but added the following as it must >> not be clear enough to others if you raised this point (thanks for >> doing so): >> >> Content filtering via a proxy can also utilize an intercepting >> certificate where >> the client's session is terminated at the proxy enabling for >> cleartext inspection >> of the traffic. A new session is created from the intercepting >> device to the >> client's destination, this is an opt-in strategy for the client, >> where the endpoint >> is configured to trust the intercepting certificat
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Hi Kathleen, Thanks for your response. Comments inline; I deleted sections that do not seem to need further discussion. Thanks! Ben. > On Feb 9, 2018, at 1:18 PM, Kathleen Moriarty > wrote: > > Hi Ben, > > Thanks again for the comments, responses and proposals are inline. > > On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell wrote: >> Ben Campbell has entered the following ballot position for >> draft-mm-wg-effect-encrypt-17: No Objection >> >> 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/ >> >> >> >> -- >> COMMENT: >> -- >> >> This is a considerably better document than the previous versions I have >> reviewed. Thanks for all that work. But of course, I still have some comments >> :-) >> >> Substantive Comments: >> >> -2.2.2, 2nd paragraph: "... for example, many >> forms of communications (from isochronous/real-time to bulk/elastic >> file transfer) will take place over HTTP port 80 or port 443, so only >> the messages and higher-layer data will make application >> differentiation possible." >> >> I'm confused about the use of port 443 in that sentence; presumably traffic >> to >> 443 will be encrypted and not allow differentiation using higher-layer data. > > TLS 1.2 does leave data exposed for differentiation, SNI for example. > TLS 1.3 leaves some, but there will be options to encrypt SNI at some > point in the future. The response to ALPN will be returned in > encrypted extensions in TLS 1.3. These are just the examples that > come readily to mind and are included in the document. > > Do you think additional text is needed in this section around the port > 443 example or is this covered enough later in the document? No, I think that's fine. I was not thinking about information revealed by TLS itself. > > >> >> -2.2.4: This section lacks a discussion of the impact of encryption. > > Good point. I added one sentence at the edn of the second to last > paragraph and modified the last paragraph as follows. Let me know if > this looks good or you would like to see changes. > > If impacted by encryption, performance enhancing proxies could make > use of routing > overlay protocols to accomplish the same task, but this results in > additional overhead. > > An application-type-aware network edge (middlebox) can further > control pacing, limit > simultaneous HD videos, or prioritize active videos against new videos, etc. > Services at this more granular level are limited with the use of > encryption. WFM. > >> >> -2.2.5, last paragraph: I understand that techniques that require endpoint >> cooperation might be out of scope, but the tone of this paragraph makes it >> sound like requiring endpoint cooperation is a negative. Is that the intent? > > Good catch, no that was not the intent and is in conflict with the > following sentence. How about the following modification: > >Alternate approaches are in the early phase of being explored to > allow caching of >encrypted content. These solutions require cooperation from > content owners and >fall outside the scope of what is covered in this document. > Content delegation >allows for replication with possible benefits, but any form of > delegation has the >potential to affect the expectation of client-server confidentiality. WFM. […] >> >> -2.3.1: I think it might be worth mentioning that an "intercepting >> certificate" >> requires endpoints to be configured to trust that certificate. (I assume we >> are >> not talking about the more unsavory practice of certificates that >> misrepresent >> their subjects. > > OK, I read this as being covered, but added the following as it must > not be clear enough to others if you raised this point (thanks for > doing so): > > Content filtering via a proxy can also utilize an intercepting > certificate where > the client's session is terminated at the proxy enabling for > cleartext inspection > of the traffic. A new session is created from the intercepting > device to the > client's destination, this is an opt-in strategy for the client, > where the endpoint > is configured to trust the intercepting certificate. Changes to > TLSv1.3 do not > impact this more invasive method of interception, where this has > the potential > to expose every HTTPS session to an active man in the middle (MitM). WFM. > >> >> -2.3.4 I concur with Adam that this section should expli
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Hi Ben, Thanks again for the comments, responses and proposals are inline. On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-mm-wg-effect-encrypt-17: No Objection > > 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/ > > > > -- > COMMENT: > -- > > This is a considerably better document than the previous versions I have > reviewed. Thanks for all that work. But of course, I still have some comments > :-) > > Substantive Comments: > > -2.2.2, 2nd paragraph: "... for example, many >forms of communications (from isochronous/real-time to bulk/elastic >file transfer) will take place over HTTP port 80 or port 443, so only >the messages and higher-layer data will make application >differentiation possible." > > I'm confused about the use of port 443 in that sentence; presumably traffic to > 443 will be encrypted and not allow differentiation using higher-layer data. TLS 1.2 does leave data exposed for differentiation, SNI for example. TLS 1.3 leaves some, but there will be options to encrypt SNI at some point in the future. The response to ALPN will be returned in encrypted extensions in TLS 1.3. These are just the examples that come readily to mind and are included in the document. Do you think additional text is needed in this section around the port 443 example or is this covered enough later in the document? > > -2.2.4: This section lacks a discussion of the impact of encryption. Good point. I added one sentence at the edn of the second to last paragraph and modified the last paragraph as follows. Let me know if this looks good or you would like to see changes. If impacted by encryption, performance enhancing proxies could make use of routing overlay protocols to accomplish the same task, but this results in additional overhead. An application-type-aware network edge (middlebox) can further control pacing, limit simultaneous HD videos, or prioritize active videos against new videos, etc. Services at this more granular level are limited with the use of encryption. > > -2.2.5, last paragraph: I understand that techniques that require endpoint > cooperation might be out of scope, but the tone of this paragraph makes it > sound like requiring endpoint cooperation is a negative. Is that the intent? Good catch, no that was not the intent and is in conflict with the following sentence. How about the following modification: Alternate approaches are in the early phase of being explored to allow caching of encrypted content. These solutions require cooperation from content owners and fall outside the scope of what is covered in this document. Content delegation allows for replication with possible benefits, but any form of delegation has the potential to affect the expectation of client-server confidentiality. > > -2.3, section title: The title is only partially evocative of the section > content. I suggest adding "content filtering". Done, thanks for the suggestion. We were hesitant to make any changes to this section once Mirja was happy, so these suggestions are very helpful. > > -2.3.1: I think it might be worth mentioning that an "intercepting > certificate" > requires endpoints to be configured to trust that certificate. (I assume we > are > not talking about the more unsavory practice of certificates that misrepresent > their subjects. OK, I read this as being covered, but added the following as it must not be clear enough to others if you raised this point (thanks for doing so): Content filtering via a proxy can also utilize an intercepting certificate where the client's session is terminated at the proxy enabling for cleartext inspection of the traffic. A new session is created from the intercepting device to the client's destination, this is an opt-in strategy for the client, where the endpoint is configured to trust the intercepting certificate. Changes to TLSv1.3 do not impact this more invasive method of interception, where this has the potential to expose every HTTPS session to an active man in the middle (MitM). > > -2.3.4 I concur with Adam that this section should explicitly mention > "cross-site user tracking" as one of the common motivations for header > insertion/enrichment. I think it should also include a mention of RFC 8165. Adam's request has already been addressed by adding
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
On Wed, Feb 7, 2018 at 11:04 PM, Ben Campbell wrote: > > >> On Feb 7, 2018, at 9:08 PM, Spencer Dawkins at IETF >> wrote: >> >> -2.2.1: Please expand "QUIC" and add a citation. >> >> QUIC started out as an acronym (and went through two or three variations), >> but sometime during the chartering process, the expansion was dropped. QUIC >> is both the working group name and abbreviation in >> https://datatracker.ietf.org/wg/quic/about/. > > Ah, good point. > >> >> But citations are good :-) > > Yes :-) > Thanks for the clarification, we'll take care of the updates! > Ben. > -- Best regards, Kathleen ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
> On Feb 7, 2018, at 9:08 PM, Spencer Dawkins at IETF > wrote: > > -2.2.1: Please expand "QUIC" and add a citation. > > QUIC started out as an acronym (and went through two or three variations), > but sometime during the chartering process, the expansion was dropped. QUIC > is both the working group name and abbreviation in > https://datatracker.ietf.org/wg/quic/about/. Ah, good point. > > But citations are good :-) Yes :-) Ben. signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Following up on an obscure point ... On Tue, Feb 6, 2018 at 11:40 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-mm-wg-effect-encrypt-17: No Objection > > 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/ > > > > -- > COMMENT: > -- > > This is a considerably better document than the previous versions I have > reviewed. Thanks for all that work. But of course, I still have some > comments > :-) > > Substantive Comments: > > -2.2.2, 2nd paragraph: "... for example, many >forms of communications (from isochronous/real-time to bulk/elastic >file transfer) will take place over HTTP port 80 or port 443, so only >the messages and higher-layer data will make application >differentiation possible." > > I'm confused about the use of port 443 in that sentence; presumably > traffic to > 443 will be encrypted and not allow differentiation using higher-layer > data. > > -2.2.4: This section lacks a discussion of the impact of encryption. > > -2.2.5, last paragraph: I understand that techniques that require endpoint > cooperation might be out of scope, but the tone of this paragraph makes it > sound like requiring endpoint cooperation is a negative. Is that the > intent? > > -2.3, section title: The title is only partially evocative of the section > content. I suggest adding "content filtering". > > -2.3.1: I think it might be worth mentioning that an "intercepting > certificate" > requires endpoints to be configured to trust that certificate. (I assume > we are > not talking about the more unsavory practice of certificates that > misrepresent > their subjects. > > -2.3.4 I concur with Adam that this section should explicitly mention > "cross-site user tracking" as one of the common motivations for header > insertion/enrichment. I think it should also include a mention of RFC 8165. > > -5.2: This section doesn't seem to include discussion of the impact of > encryption. > > Editorial and nits: > > -IDNits finds a number of unused references, and a few other reference > issues. > Please check. > > - Abstract: 2nd sentence is hard to parse, and ends with a comma splice. > > - 1, 2nd paragraph: " The following informational >documents consider the end to end (e2e) architectural principle, a >guiding principle for the development of Internet protocols [RFC2775] >[RFC3724] [RFC7754]." > > Is the comma correct? It currently reads along the lines of "The documents > consider the e2e principle, and we think that it is a guiding > principle...", > but I think you might mean "The documents consider the e2e to be a guiding > principle..." > > -1, 3rd paragraph: "... (including methods for network >endpoints where applicable)..." > Should that say "methods that rely on network endpoints"? > > -2.1.1: Please expand "CAIDA" > > -2.1.1: Paragraph starting with " >When using increased encryption, operators lose a source of data that >may be used to debug user issues." > I don't think the operators are the ones using the encreased encryption in > that > sentence. Perhaps "When endpoints use increased encryption..." or even > (When > increased encryption is used..." > > -2.1.3, 2nd paragraph: "The ability to examine layers and payloads >above transport provides a new range of filtering opportunities at >each layer in the clear. " > Should "new range" be "increased range"? > > -2.1.3, third paragraph: The last sentence seems out of place. Is the > point of > the paragraph to point out that the use of these monitoring techniques for > DoS > mitigation can't be distinguished from the use of them for privacy > violation? > > -2.2.1: Please expand "QUIC" and add a citation. > QUIC started out as an acronym (and went through two or three variations), but sometime during the chartering process, the expansion was dropped. QUIC is both the working group name and abbreviation in https://datatracker.ietf.org/wg/quic/about/. But citations are good :-) > > -2.2.3, last sentence: Sentence fragment. > > -2.2.4, first sentence: Comma splice. > > -2.2.5, first paragraph: " Encryption of packet contents at a given >protocol layer usually makes DPI processing of that layer and higher >layers impossible. " > > This sentence seems misplaced; the section is not about DPI. > > -- same paragraph: I don't understand the point(s) of the last two > sentences. > > -2.2.5, third paragraph: "The Enhanced Multimedia Broadcast
Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Hi Ben, Thanks for the detailed comments. We will fold them into a revision after the telechat (as I have no time before). We have some editorial ones from Ben that will be folded in as well. We were hesitant to change anything that was not requested as we didn't want to leave the document in a hung state, otherwise there would have been more editorial work in section 2 in particular prior to posting this version. Best regards, Kathleen On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-mm-wg-effect-encrypt-17: No Objection > > 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/ > > > > -- > COMMENT: > -- > > This is a considerably better document than the previous versions I have > reviewed. Thanks for all that work. But of course, I still have some comments > :-) > > Substantive Comments: > > -2.2.2, 2nd paragraph: "... for example, many >forms of communications (from isochronous/real-time to bulk/elastic >file transfer) will take place over HTTP port 80 or port 443, so only >the messages and higher-layer data will make application >differentiation possible." > > I'm confused about the use of port 443 in that sentence; presumably traffic to > 443 will be encrypted and not allow differentiation using higher-layer data. > > -2.2.4: This section lacks a discussion of the impact of encryption. > > -2.2.5, last paragraph: I understand that techniques that require endpoint > cooperation might be out of scope, but the tone of this paragraph makes it > sound like requiring endpoint cooperation is a negative. Is that the intent? > > -2.3, section title: The title is only partially evocative of the section > content. I suggest adding "content filtering". > > -2.3.1: I think it might be worth mentioning that an "intercepting > certificate" > requires endpoints to be configured to trust that certificate. (I assume we > are > not talking about the more unsavory practice of certificates that misrepresent > their subjects. > > -2.3.4 I concur with Adam that this section should explicitly mention > "cross-site user tracking" as one of the common motivations for header > insertion/enrichment. I think it should also include a mention of RFC 8165. > > -5.2: This section doesn't seem to include discussion of the impact of > encryption. > > Editorial and nits: > > -IDNits finds a number of unused references, and a few other reference issues. > Please check. > > - Abstract: 2nd sentence is hard to parse, and ends with a comma splice. > > - 1, 2nd paragraph: " The following informational >documents consider the end to end (e2e) architectural principle, a >guiding principle for the development of Internet protocols [RFC2775] >[RFC3724] [RFC7754]." > > Is the comma correct? It currently reads along the lines of "The documents > consider the e2e principle, and we think that it is a guiding principle...", > but I think you might mean "The documents consider the e2e to be a guiding > principle..." > > -1, 3rd paragraph: "... (including methods for network >endpoints where applicable)..." > Should that say "methods that rely on network endpoints"? > > -2.1.1: Please expand "CAIDA" > > -2.1.1: Paragraph starting with " >When using increased encryption, operators lose a source of data that >may be used to debug user issues." > I don't think the operators are the ones using the encreased encryption in > that > sentence. Perhaps "When endpoints use increased encryption..." or even (When > increased encryption is used..." > > -2.1.3, 2nd paragraph: "The ability to examine layers and payloads >above transport provides a new range of filtering opportunities at >each layer in the clear. " > Should "new range" be "increased range"? > > -2.1.3, third paragraph: The last sentence seems out of place. Is the point of > the paragraph to point out that the use of these monitoring techniques for DoS > mitigation can't be distinguished from the use of them for privacy violation? > > -2.2.1: Please expand "QUIC" and add a citation. > > -2.2.3, last sentence: Sentence fragment. > > -2.2.4, first sentence: Comma splice. > > -2.2.5, first paragraph: " Encryption of packet contents at a given >protocol layer usually makes DPI processing of that layer and higher >layers impossible. " > > This sentence seems misplaced; the section is not about DPI. > > -- same paragraph: I don't underst
[OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-mm-wg-effect-encrypt-17: No Objection 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/ -- COMMENT: -- This is a considerably better document than the previous versions I have reviewed. Thanks for all that work. But of course, I still have some comments :-) Substantive Comments: -2.2.2, 2nd paragraph: "... for example, many forms of communications (from isochronous/real-time to bulk/elastic file transfer) will take place over HTTP port 80 or port 443, so only the messages and higher-layer data will make application differentiation possible." I'm confused about the use of port 443 in that sentence; presumably traffic to 443 will be encrypted and not allow differentiation using higher-layer data. -2.2.4: This section lacks a discussion of the impact of encryption. -2.2.5, last paragraph: I understand that techniques that require endpoint cooperation might be out of scope, but the tone of this paragraph makes it sound like requiring endpoint cooperation is a negative. Is that the intent? -2.3, section title: The title is only partially evocative of the section content. I suggest adding "content filtering". -2.3.1: I think it might be worth mentioning that an "intercepting certificate" requires endpoints to be configured to trust that certificate. (I assume we are not talking about the more unsavory practice of certificates that misrepresent their subjects. -2.3.4 I concur with Adam that this section should explicitly mention "cross-site user tracking" as one of the common motivations for header insertion/enrichment. I think it should also include a mention of RFC 8165. -5.2: This section doesn't seem to include discussion of the impact of encryption. Editorial and nits: -IDNits finds a number of unused references, and a few other reference issues. Please check. - Abstract: 2nd sentence is hard to parse, and ends with a comma splice. - 1, 2nd paragraph: " The following informational documents consider the end to end (e2e) architectural principle, a guiding principle for the development of Internet protocols [RFC2775] [RFC3724] [RFC7754]." Is the comma correct? It currently reads along the lines of "The documents consider the e2e principle, and we think that it is a guiding principle...", but I think you might mean "The documents consider the e2e to be a guiding principle..." -1, 3rd paragraph: "... (including methods for network endpoints where applicable)..." Should that say "methods that rely on network endpoints"? -2.1.1: Please expand "CAIDA" -2.1.1: Paragraph starting with " When using increased encryption, operators lose a source of data that may be used to debug user issues." I don't think the operators are the ones using the encreased encryption in that sentence. Perhaps "When endpoints use increased encryption..." or even (When increased encryption is used..." -2.1.3, 2nd paragraph: "The ability to examine layers and payloads above transport provides a new range of filtering opportunities at each layer in the clear. " Should "new range" be "increased range"? -2.1.3, third paragraph: The last sentence seems out of place. Is the point of the paragraph to point out that the use of these monitoring techniques for DoS mitigation can't be distinguished from the use of them for privacy violation? -2.2.1: Please expand "QUIC" and add a citation. -2.2.3, last sentence: Sentence fragment. -2.2.4, first sentence: Comma splice. -2.2.5, first paragraph: " Encryption of packet contents at a given protocol layer usually makes DPI processing of that layer and higher layers impossible. " This sentence seems misplaced; the section is not about DPI. -- same paragraph: I don't understand the point(s) of the last two sentences. -2.2.5, third paragraph: "The Enhanced Multimedia Broadcast/ Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate delivering same stream to different users, using either unicast or multicast depending on channel conditions to the user. " I can't parse that sentence. -2.3.3: Please make the "SHOULD" lower case. Since this document does not use RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a literal quote. -3: "Businesses understanding the threats of monitoring in hosted environments only increased that pressure to provide more secure access and session encryption" Why "only"? That se
