Hi Ben,

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

On Wed, Feb 7, 2018 at 12:40 AM, Ben Campbell <b...@nostrum.com> 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/
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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

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

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

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.

> Editorial and nits:
> -IDNits finds a number of unused references, and a few other reference issues.
> Please check.

Will do, thanks.
> - 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"?

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

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

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

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

That makes sense, updated.
> -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?

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

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!

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

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.

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

Done, thanks for catching that!
> -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.

Removed, thanks.

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

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.

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

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
> filtering"?
Fixed, thanks.

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

Monitor for.  Fixed, thanks!
> -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..."

Fixed, thanks!
> -7 and subsections: It looks like the editing of this section is not finished;
> 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
> articles.

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

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

Thanks for helping to improve the document!


Best regards,

OPSAWG mailing list

Reply via email to