Subject: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 06 Feb 2018 21:40:44 -0800

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 seems to suggest one would expect some different result.

-3.1.2: This section is about Hosting SPs, but the last two paragraphs seem to
be about ASPs. While I realize those may sometimes be the same organization,
they are architecturally distinct.

-3.2.2: "STARTTLS ought have zero effect..."
"Ought to have zero effect" or "has little effect"?  (If the former, it's safe
to say "should" since this draft does not use RFC 2119 keywords.)

-3.2.2, last paragraph: Should "SPAM filtering" be "content-based SPAM
filtering"?

-4.2: What does it mean for tools to "use" keywords? Does this mean "search
for" or "monitor for" keywords?

-5.4: This seems to say that "Detection and Mitigations" involves thousands of
hosts, etc. I think the point is that the botnets themselves may involve
thousands of hosts..."

-7 and subsections: It looks like the editing of this section is not finished;
several sections indicate they are to be deleted.

-7.4: Please describe what you mean by "transit proxies".

I can't parse item 4. The entire section could use proofreading for missing
articles.

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 7 Feb 2018 09:19:01 -0500

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

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Feb 2018 21:08:29 -0600

Following up on an obscure point ...

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

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Feb 2018 22:04:59 -0600

> On Feb 7, 2018, at 9:08 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 7 Feb 2018 23:13:55 -0500

>> But citations are good :-)

Thanks for the clarification, we'll take care of the updates!

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 14:18:46 -0500

Hi Ben,

Thanks again for the comments, responses and proposals are inline.

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

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.

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

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

> not talking about the more unsavory practice of certificates that misrepresent

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

> insertion/enrichment. I think it should also include a mention of RFC 8165.

Adam's request has already been addressed by adding that text.  How
abotu the following paragrpah to address the addition of an 8165
reference and for it to make sense in context of the document:

    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.

> -5.2: This section doesn't seem to include discussion of the impact of

I added the following to address your comment, thank you.

The impact of encryption can be understood from their documented use
cases I-D.ietf-dots-use-cases.

> -IDNits finds a number of unused references, and a few other reference issues.

Will do, thanks.
> - Abstract: 2nd sentence is hard to parse, and ends with a comma splice.

Fixed.
> but I think you might mean "The documents consider the e2e to be a guiding

Fixed.
> Should that say "methods that rely on network endpoints"?

Fixed, thanks.
> -2.1.1: Please expand "CAIDA"
Done, thanks.

> increased encryption is used..."

Good catch!  I implemented the latter suggestion in case the
encryption is from a gateway device (IPsec tunnel mode, for example).

> Should "new range" be "increased range"?

That makes sense, updated.
> mitigation can't be distinguished from the use of them for privacy violation?

Fixing, thanks, this wasn't clear!  I deleted the sentence on DDoS
mitigation as I believe the point is made in the two paragraphs above.
This paragraph was intended to show the reasons for encryption.  I
joined the following paragraph into this one as it made sense once
that sentence had been removed.

> -2.2.1: Please expand "QUIC" and add a citation.

Citation added, thanks!  I did it on first use in the introduction and
added one for TCPcrypt too.

> -2.2.3, last sentence: Sentence fragment.

Good catch,  I edited as follows:
    Mitigating techniques such as deferred download, off-peak acceleration,
    and outbound roamers are a few examples of the areas explored in the
    associated 3GPP documents.  The documents describe the issues, the
    data utilized in managing congestion, and make policy recommendations.
> -2.2.4, first sentence: Comma splice.
Fixed.
> This sentence seems misplaced; the section is not about DPI.

Hmm, I read this as DPI being used in these functions, hence the
impact of encryption.  I'm wondering if reading the first sentence
again helps:

   The features and efficiency of some Internet services can be augmented
   through analysis of user flows and the applications they provide.

Or if I am missing something.  If so, please let me know!

> I can't parse that sentence.

Yes, Adam pointed this out as well and it has been adjusted as follows:

    The Enhanced Multimedia Broadcast/Multicast Services (3GPP eMBMS)
    utilizes trusted edge proxies to facilitate delivering the same stream to
    different users, using either unicast or multicast depending on channel
    conditions to the user.

Please let us know if that doesn't clear it up for you.

> RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a

Done, thanks for catching that!
> Why "only"? That seems to suggest one would expect some different result.

Removed, thanks.

> they are architecturally distinct.

I changed the section heading for 3 to include application service
providers as the document doesn't have another place for that content.
I agree with the distinction you are making, let me know if this is an
okay fix.

> to say "should" since this draft does not use RFC 2119 keywords.)

This wording came from Stephen in his original AD review, so we stuck with it.
Ought to has been pretty common practice in RFCs, but I guess we used
to see this more at the beginning of my term as an AD.  I'll add the
to and if anyone else wants it changed, it's not a big deal.

> -3.2.2, last paragraph: Should "SPAM filtering" be "content-based SPAM
Fixed, thanks.

> for" or "monitor for" keywords?

Monitor for.  Fixed, thanks!
> hosts, etc. I think the point is that the botnets themselves may involve

Fixed, thanks!
> several sections indicate they are to be deleted.

Yes, these were left for editing tracking purposes and diff
comparisons.  It should be safe to remove them now.
> -7.4: Please describe what you mean by "transit proxies".

It's a proxy used in transit as opposed to a proxy on the edge of a
network, "edge proxy".  Seems to be a common term in a google search,
but I'll clarify the text.  Thanks.

> I can't parse item 4. The entire section could use proofreading for missing

I did a little work and may do another sweep of it.  Thanks.

> nature of this draft--but that situation is rare in practice.)

We'll think about this a bit more, thanks.

Thanks for helping to improve the document!

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Feb 2018 13:35:57 -0600

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

No, I think that's fine. I was not thinking about information revealed by TLS itself.

>   Services at this more granular level are limited with the use of

WFM.

>    potential to affect the expectation of client-server confidentiality.

WFM.

[…]

>     to expose every HTTPS session to an active man in the middle (MitM).

WFM.

>    methods that follow this and other guidance would be helpful to

Looks good.

> cases I-D.ietf-dots-use-cases.

Okay.

>> Editorial and nits:

[…]

> Or if I am missing something.  If so, please let me know!

No, I apparently lost state between the first sentence and the sentence I commented on :-)

[…]

> I agree with the distinction you are making, let me know if this is an

ThaWFM.

> to and if anyone else wants it changed, it's not a big deal.

I did not mean to complain about “ought to” per se, but I was wondering why the text used a subjunctive from for what seemed like a statement of fact. Was the point to talk about the way things should be, or the way things are (or maybe are expected)?

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 13 Feb 2018 16:58:04 -0500

Hi Ben,

Thanks for checking back through the responses.  inline

> No, I think that's fine. I was not thinking about information revealed by TLS itself.

Thanks for confirming.

Thanks!
> No, I apparently lost state between the first sentence and the sentence I commented on :-)

Happens to all of us :-)

> I did not mean to complain about “ought to” per se, but I was wondering why the text used a subjunctive from for what seemed like a statement of fact. Was the point to talk about the way things sho…

I'm happy to change and will do so :-) . I'll use should to capture
what was intended.

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

Thank you, again!
Kathleen

-- 

Best regards,
Kathleen

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 13 Feb 2018 22:56:05 +0000

Hi Ben and Kathleen, on References:
...
<snip>
...
> > 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.
> 
[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