Hi Kathleen,

Thanks for your response. Comments inline; I deleted sections that do not seem 
to need further discussion.



> On Feb 9, 2018, at 1:18 PM, Kathleen Moriarty 
> <kathleen.moriarty.i...@gmail.com> wrote:
> 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?

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

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

Looks good.

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


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

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


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

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

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

Attachment: signature.asc
Description: Message signed with OpenPGP

OPSAWG mailing list

Reply via email to