Re: [saag] AD sponsoring Effect of Ubiquitous Encryption

[Kathleen Moriarty <[e-mail]>]

Hi Stephen,

First, thank you for your detailed review, this is very helpful to
improve the document.  Al's on vacation, so I will respond in-line for
us and take the blame later if needed :-)

On Sun, Jan 22, 2017 at 3:42 PM, Stephen Farrell
<[e-mail]> wrote:
>
>
> Hi again,
>
> First, thanks to Paul Hoffman for being willing to be the
> document shepherd for this. And to the authors for what
> will be a fine RFC when it's done.


Thank you, Paul!
>
>
> Second, I've done my AD review of this and there are a set
> of things that need fixing before we'll be ready for IETF
> last call. At minimum there are still a few placeholder
> sections of text (2.3,2.3.1,3.2,2), but I also have many
> comments that cumulatively raise to the level where we
> should address a bunch of those before IETF LC, even
> though many (but not all) of my comments are relatively
> nitty. I think that almost all of those should be pretty
> easy to resolve, so we should still be able to get this
> done before IETF98 I hope.
>
> My AD review is below.
>
> Cheers,
> S.
>
> general: I wonder if we're dealing with all possible effects
> or only with those relevant to network management, security
> ad privacy? For example, more encryption does prevent some
> advertising insertion, but whether or not that is in scope
> here is unclear to me. Should it be?


I'd constrain it a little further to what we and others contributed.
We certainly could have missed some items in network management,
operation, security and privacy.  I'll look at the introduction to see
if the text can make it more clear on what the document covers.

We encouraged the security and operator communities to contribute as
best we could.

>
> - title: I wonder would "Effects of Much More Common
> Encryption" be a better title? Ubiquitous is never actually
> going to happen, nor is it required for many of the effects
> to be seen. (And there is defo. >1 effect to be seen.) Or,
> you could keep the title, but explain in the text that you
> really mean "much more common."


Let me think on this a bit to see if I can come up with an another
title or we'll just note exactly what is meant in the introduction as
suggested.

>
>
> - abstract: "solve these problems" is a tad one-sided in that
> it doesn't recognise the valid reasons for more
> confidentiality. I think it's important that the abstract
> recognise that we're here documenting one set of consequences
> of what is a valid set of trade-offs and not describing a set
> of problems caused for no good reason.  I think that it's
> important to set the right tone early for this one - if we
> don't then some readers who want better privacy may be more
> likely to be dismissive, which'd be a shame.


How about,
     "This draft seeks only to record the current state to assist in the
      development of alternate options to achieve the intended purpose of the
      documented practices.

>
> - abstract: "will impact" is maybe no longer the correct
> tense - we've seen some of these impacts already I think, so
> maybe "are impacting" or just "impact" is better?


I think just impacts works, thanks.

>
>
> - abstract: "more drastic" seems unfounded - what do you
> really want to say there?


This is thinking from the operators perspective.  I do think this is
drastic for some and that we should recognize the large change in
their world.  Do you have another suggestion that conveys this
understanding?  Bringing both sides of this together is really the
goal.

>
>
> - intro: I'm not sure "primarily a passive attack" is right.
> Maybe easiest to just delete that clause as I don't think
> it's needed here. You could add a reference to RFC7624 for
> those who'd like more detail.


Sure there can be active attacks that lead to pervasive monitoring,
and I'm fine with that change.

>
>
> - intro, 2nd para: I'm not sure what you mean referring to
> "many attackers"? That sentence doesn't seem to make sense
> as-is.
>

Thanks, I see what you mean.  The text isn't as straightforward as it
could be.  I think we were avoiding saying terrorists, but should just
said bad actors.

Old:
      Many attackers and those
      that pose a greater threat are already using strong encryption and tools
      like TOR <xref target="TOR"/> to prevent active attacks on their data
      streams
New:
      Bad actors, for example criminals or terrorists, could easily
employ the use of strong encryption with tools like TOR <xref
target="TOR"/> to prevent active attacks on their data streams, which
are possible with OS.

>
> - intro: the UTA document references need to be updated


Done, thanks.

>
>
> - intro: the 30% figure is probably out of date, please check
> again (or add a date as done with the others).


Changed to spring 2015.  Will try to get a new figure if possible.

>
>
> - intro: "for corporate users" would be better removed - we
> care as much about non-corporate users after all


Hmm, this is referring to the statistic for encrypted content, which
was specific to corporate users. While we may care about non-corporate
users more, this is an easier statistic to get since they are behind a
firewall and corporate network used to gather this statistic.
Non-corporate users might result in a different statistic, so I'd
prefer to leave this as-is.

>
> - intro: "TLS over HTTP" is backwards, as is "TLS over XMPP"


Odd, thanks for catching this.

>
> - intro: "Although this does provide..." - that sentence
> isn't right, passive is not the opposite of e2e, I think you
> want s/passive wiretapping/transport layer attacks/


Updated, thanks.
>
>
> - intro: You mention OTR, but the cooler kids these days use
> signal/telegram (though I don't for platform reasons;-).
> Might be worth checking out what to say about those, or just
> say "e.g. OTR" instead of making it seem like OTR is the only
> way to do IM e2e.


Hmm, signal seems to be for SMS on Andriod only...  or does it have a
wider reach?  If so, I'd rather not mention that.  Telegram seems to
be an app that relies on SMS and it's own messaging format, so it
doesn't provide encryption for XMPP.  If I add this, I'd have to add
other messaging apps as well.  I think it's fine to leave as-is with
standards mentioned only.
https://en.wikipedia.org/wiki/Telegram_(software)

>
>
> - intro, 2nd last para: that one is very good


Thanks :-)  It's the goal of the draft.
>
>
> - intro, last para: you don't mention enterprise networks
> here, worth a mention?


*Hmm, let me think about that a bit and we can come back to this one.

>
>
> - section 2, 2nd para: I think you could do with a forward
> reference or example to the "opterational practices that
> require cleartext" or maybe better is to s/require/previously
> depended on/


Took your suggested text, thanks.

>
>
> - 2: "TLS over SMTP" - backwards again


Odd. Fixed, thanks.
>
>
> - 2: "The EFF reported..." that needs a reference

added informative
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
>
>
> - 2: I'm not at all sure encryption "prevents" load
> balancing, in fact I'm pretty sure it does not prevent that


This was on the content.  Would you prefer to see it reworded/expanded?

>
>
> - 2: "on the decline now that they are exposed through the
> media" - I think it'd be better to remove that sentence - it
> doesn't add much and there are more details better described
> later I'm sure.


I cut out the first part, leaving the explanation...
>
>
> - 2.1: this sections seems mixed between middleboxes and
> mobile, probably as a result of iterative editing. Not sure
> how best to fix.

Sure, the first part mixes multiple ways fingerprinting is used and
one is not middle boxes at all, but I'm not sure I want to separate
that out and make the document longer... but if needed we can.

*For the rest of the section, we are running into the many contributor
problem and it's not clear how to make this better, but I'll think
about it more.

>
>
> - 2.1, last para: Is that really a middlebox function? I
> thought most of the examples given were cases of end systems
> (web servers) impinging on privacy and not middleboxes (and
> the naughty web servers are not affected by encryption so
> aren't really in scope)


*No, same as the last part of the subsection on fingerprint analysis.
We could remove it or break it out into another section.  If we break
it out into another section, the content may feel repetitive.
>
>
> - 2.1.3: I don't think DPI aims to improve "features and
> efficiency"


That was an operator's perspective.  Somehow we need to have both a
security and operators perspective seen so we can help each other.
The sentence says they are augmented, not improved, is there really an
issue keeping this text?

>
>
> - 2.1.3: "must be known" is overstated - again I think we
> want to always phrase it as "has previously been assumed to
> be required" or similar


This was contributed text, so the functions they were performing, in
the way they were being performed, might require the the traffic type
to be known.  I agree the text around this does not make that clear. I
am hesitant to change the intended meaning without what seems like the
additional context needed.

How about, "has been required to date".  I'd really like to respect
the operators views and have them documented as they see it.

>
> - 2.1.4: I think compression could (and maybe should) be
> separated out - one of the things CRIME has shown us is that
> we had more to learn about how to combine compression and
> encryption. I also think most compression is not done/undone
> at middleboxes, nor does it relate to monitoring so
> compression doesn't seem to fit well in 2.1. (Transcoding
> however might fit in some middlebox section, but is not
> compression.)


OK, I see your perspective, but will try to shed light on the context
of this section.  This was contributed from GSMA.  They have been
using compression in this way and see a change in operations as a
result of the use of encryption on the wire. I believe it is used in
gateway situations from previous discussions.  The point in this
section is to note the practice and that encryption presents a problem
for this operational practice.  It's not suggesting encryption with
compression as a solution, rather saying that some operators may
resort to attempts to prevent/break encryption to allow for the
compression they see as necessary to deliver services.  It's going to
break/is breaking and this just acks that point.

>
>
> - 2.1.5: s/law agencies/law enforcement agencies/ is the
> usual term, and LEAs are not the only entities that insist on
> this kind of thing - considering censorship.

updated, thanks.
>
>
> - 2.1.5: "sites promoting anorexia" seems like an odd
> example, but I think in any case it'd be better to generalise
> the examples a bit


Deleted that text.

>
>
> - 2.1.5: DNS queries do not "reveal" URLs. And the described
> mechanism seems quite odd.
>

Sure, looks like some flowery language inaccurately describing what
was intended.  I changed it to the following:

          Although filtering can be
          done by many methods one common method occurs when a DNS lookup
          of a hostname in a URL which appears on a government or recognized
          block-list.

> - 2.1.5: The 3rd last para about  "TLS proxies" and "future
> versions of HTTP and TCP" is not clear to me. Is that really
> needed?


Hmm, I'm guessing this was referring to TCPInc work, but I think
deleting the paragraph should be fine (scream now if you were the
contributor and disagree) since the text concludes with a statement
that this is not the case and has not been standardized.

>
>
> - 2.1.5: Parental controls might deserve it's own subsection
> - it differs in that the endopints are involved, which I
> think means that the effects of e.g. TLS on the changes
> required to the service are different from cases where an
> external party (govt/SP/whoever) imposes the filtering.


Done as a subsection of this section for now.  Thanks.

>
>
> - 2.1.6.3: I think you need a reference to RFC2804 here. The
> IETF does not to LI in standards, for the (good) reasons
> stated therin. So this may be a case where the effects of
> crypto do enhance existing IETF policy but also counter
> existing policies of other entities. But we should not ignore
> the former (IETF) policy - we ought not claim here that one
> or the other are better, but just ack the tussle.


Done, thanks.
>
>
> - 2.1.6.4: MTAs do trypically have cleartext access, so what
> kind of spam/malware filtering do you mean there?  How does
> that relate to the mail architecture? (There's an RFC for
> that that ought be ref'd.) If section 5 does cover this well,
> then I'd say removing this section would be good as it add
> nothing much that I can see.


Deleted.
>
>
> - 2.2: Do we have evidence that the decrease of measurement
> accuracy has actually lead to a decrease in repair
> efficiency? I'm not convinced - it doesn't seem like a crazy
> proposition, but nor does it seem like a tautology. (What
> metric for efficiency of repair is there that could be mapped
> to visibility of different protocol layers?)


*This is from Al (I believe), so I suspect it is backed up from
operational testing.

>
> - 2.2, 2nd para: This is repetitive. Making the point once is
> enough.


Hmm, I deleted the last sentence, but think the example may be helpful
within the operator community.

>
>
> - 2.3 and 2.3.1: What is the intent here? These sections seem
> to be content free. Looks like a placeholder that never got
> filled in? (Not unreasonable as it's hard to see real
> downsides to encryption of inter-DC traffic.) These need to
> be fixed or deleted. Probably deleted is better. (Certainly
> easier.) That needs fixing before IETF LC.


Yes, deleted.

>
>
> 3.1.1, 1st para: I'm not clear how session monitoring of
> cleartext is needed for SLA evaluation. Maybe an example of
> some specific thing needed would helpa but I'm not seeing an
> input to SLA evaluation here. (I do see how logs can be
> useful there.)


I can't figure it out either, but changed the text to:

          The use of session encryption to access hosted
          environments limits access restrictions to the metadata
described below.

It goes on to describe 2-tuples and 5-tuples below.

>
> 3.1.1 (and elsewhere): s/mobile clients/clients/ - while some
> of thie text relates to the marnew w/s, it ought only specify
> mobile clients where those are specifically relevant, an in
> this case, and others, they're not.


Done here and I'll have to look elsewhere as well.

>
>
> 3.1.2: "cyber-security" and "cyber-attack" please avoid
> thosse ill-defined marketing terms unless you really need and
> can justify them


Agreed, changed to security.

>
>
> 3.1.1: Is "malware explosion" a generally known term? I think
> detection is sufficient and searing for "malware explosion"
> doesn't turn up what I think you mean. (I'm guessing you mean
> unzipping etc.)


That may be what was meant, but I just deleted explosion for now.  I
think this came from Nalini and it must have slipped through my edit
pass & Al's.  If something else was intended here that is important,
she can chime in.

>
>
> 3.1.2, last para: I'm not clear how this para fits here or in
> this document in general. Not sure if that's just me or if
> some better linkage is needed, or even if the text would be
> better moved or deleted.


*Hmm, I see how this relates to SPs, but not to this subsection.  I'm
not sure of the contributor as it may be tied to application content,
but you are right - this text doesn't flow and that is not clear from
the paragraph,

>
>
> 3.2.1: I'm not sure I agree with this, at least as stated.
> Wouldn't passive monitoring of ciphertext be just as
> effective for the SLA metrics mentioned in almost all cases?


Hmm, so I'm trying to decipher the text as well.  What I can surmise
is that the impediments to performance and availability are the
"interferences".  Some things that interfere with traffic might be
seen outside of 2-tuples and 5-tuples more easily.  For the metrics
themselves, I agree with you.  However, they may know the cause of the
"interference"  with visibility into the traffic.

Perhaps adding the sentence:

          "The actual SLA metrics may not be effected by
          encryption, however visibility of interferences may be limited."

>
> 3.2.2: "[Need descriptions for..." The rest of that para
> seems like placeholder text that needs fixing before IETF LC.


deleted this paragraph.  The rest flowed well enough and this was a
placeholder for contributions.
>
>
> 3.2.2: I think it'd be worth saying somewhere here that
> STARTTLS ought have zero effect on anti-SPAM etc. for SMTP
> traffic but is only an issue in corner-cases for e.g. hosters
> who want to scan outbound port 25 traffic in case their
> cusomters have suffered breaches and start sending spam.  (At
> least that's my understanding.) PGP or S/MIME do of course.


OK, consider yourself the contributor for the above removed paragraph.
I edited the above slightly.

>
> 3.2.2: What header encryption efforts are meant here? I'm not
> familiar with anything doing exactly that. Or maybe it's just
> a phrasing issue? Or perhaps this text is a bit old and OBE?
> (I mean that initial hopes that we initiate work to to
> encrypt e.g. Subject seem to be currently moribund.)


This is old from the list that we started a while back on the topic
that I don't think went anywhere.  I'll delete it, but think we should
have something in there about some of the other efforts - just
mentioning dark mail and proprietary solutions.

>
> 3.2.2: I'm not sure the bullet list here is a good idea.
> E.g. it omits DKIM related things and SPF related things.
> Maybe check with some anti-spam folks if keeping this list?


I removed the whole section as it didn't make sense without the email
header thing that has gone away...

>
>
> 3.3: I wondered if this section would be better reorganised
> into a structure based on where the keys are located. Not
> sure but that might be a clearer way to distinguish the
> various kinds of encrypted storage. (Feel free to ignore this
> suggestion if it doesn't resonate.)


Yeah, it's more complicated than that as even on similar platforms,
the solutions can differ.  If KMIP is used, then you have a standard t
go off of, but that's not always the case.

>
>
> 3.3.1: I found this sub-section confusing and not useful.
> Would suggest simplifying it a lot.  The term "burst data"
> isn't that clear.


Hmm, I removed the word burst, but essentially, you could have a burst
of data of a certain size and the size could dictate where the burst
of data is stored.  The same application might have some data stored
locally, then some off to an external service.  I reworded to remove
the word burst and explain it better.

>
>
> - section 4: Is "for Enterprise Users" right here?

No, it should probably just be enterprises. updating, thanks.

>
>
> - 4: "harder to break" is not relevant here - at least in
> terms of algorithms, which is what that'd be interpreted as
> far as to mean. If you mean that non FS mechanisms (e.g. RSA
> key transport) provide more opportunity for decryption at
> places other than the endpoint at which the applications
> calls for decryption, but that we increasingly do want to see
> more use of FS mechanisns, and that that's a tension, then
> maybe say that.


I agree with you and deleted that clause.  Later in the paragraph, I
changed "need" to "desire".

>
>
> - 4.1: Not sure "static" is quire right - I think what you
> mean is replicated TLS server RSA private keys.


Yes, updated.
>
>
> - 4.1.1: "Enterprise users are subject to the policies of
> their organization." That is jurisdiction-dependent - at
> least in some countries (e.g. Ireland) the enterprise cannot
> breach employment laws that can touch on employee privacy.
> Such jurisdictional issues can work both ways of course,
> either re-inforcing privacy or calling for privacy to be
> eroded even more than the enterprise would wish.  Suggest
> adding "... and the jurisdictions in which the enterprise
> operates" to cover both;-)


Updated, thanks for the text.
>
>
> - 4.1.1: "These functions are critical to security and fraud
> monitoring." I don't accept that this is true of all the
> numbered elements in the list.  Supposed countermeasures for
> IP leakage for example are often ineffective (though vendors
> who sell such things will doubtless disagree;-). I'd say
> toning that down a bit would be right, e.g. s/are criticial/
> are often consided important/.


Hmm, in reading this contributed text, I would change it even more
than what you are suggesting.  The functions aren't critical to
monitoring, but rather detecting these functions are important to
effective monitoring and mitigation of malicious traffic that is not
limited to malware.  How about:

OLD:
          A significant portion of malware hides its activity within
          TLS or other encrypted protocols. This includes lateral movement,
          Command and Control, and Data Exfiltration. These functions are
          critical to security and fraud monitoring.
NEW:
          A significant portion of malware hides its activity within
          TLS or other encrypted protocols. This includes lateral movement,
          Command and Control, and Data Exfiltration. Detecting these
          functions are important to effective monitoring and mitigation of
          malicious traffic, not limited to malware.

>
> - 4.1.2: Mention of PDM reminds me that that has had a pretty
> thorough discussion related to the secdir review and issues
> relevant to this draft. Incorporating a description of that
> history would maybe be useful so that we have less pain when
> we re-do that in future for other protocols.


* Will have to go back to this as I'm not recalling this off hand and
will have to review the discussion.

>
>
> - 4.1.3: I don't accept "impossible" is correct. If we wanted
> to say that, we'd need evidence, e.g. via a set of
> references. "More onerous" would be fine if that's all we
> need to say. A number of other similar changes are needed for
> the text in 4.1.3.x as well, e.g.:


The problem here (IMO) is that vendors need to step up their logging
game.  Many of the errors could be seen if logs better identified
issues that I have been shown or that we've seen in presentations from
enterprise representatives in the IETF.  From their perspective, the
problem seems insurmountable as they don't know how they will contact
and so many vendors to increase logging and they no longer have
visibility into packet streams to detect even simple issues like
incorrect passwords..  I think we need to help (and are trying to do
so) in standards documentation calling for logging of errors.

The sentence is limited to finding things in network traces, so with
encryption, they are right... they need other methods like log
analysis.  We need to ack the problems in this draft, so how about
adding this sentence instead of changing the last one:

          Alternate methods, such as log analysis need
          improvement to fill this gap.
>
>
> - 4.1.3.1: "requires" is overstated, and what evidence is
> there for "frequently used"? I don't accept either assertion
> without evidence.


Hmm, my read of this part of the NAT section is that they use
identifier information to trace traffic, which is normal.  Up to this
point in the text, I am reading it in a way that they can do this
through logs.  I have more of an issue with the following paragraphs.
Requires just means that if they are going to follow a trace, they
need some identifiers to do so - 2-tuples, 5-tuples and how they
change (logs) through a device that performs NAT.

I propose changing this instead:
OLD:
            Combine this with the fact that users are often allocated
            randomly by load balancers to all these devices, the network
            troubleshooter is often left with no option in today's environment
            except to trace all packets at a particular layer, decrypt them
            all, and look at the payload to find a user session.</t>
NEW:
            Combine this with the fact that users are often allocated
            randomly by load balancers to all these devices, the network
            troubleshooter is often left with very few options in today's
            environment due to poor logging implementations in applications.
            As such, network troubleshooting is used to trace packets at a
            particular layer, decrypt them, and look at the payload to find a
            user session.</t>

and
OLD:
      Endpoints
      typically don't have the capacity to handle this level of network
      packet capture, so out-of-band networks of robust packet brokers and
      network sniffers that depend on static RSA private keys accomplish
      this task today.

NEW:

      Endpoints typically don't have the capacity to handle
      this level of network packet capture, so out-of-band networks of
      robust packet brokers and network sniffers that use techniques such
      as copies of TLS RSA private keys accomplish this task today.
>
>
> - 4.1.3.x: there are more of the above that need fixing

**Additional cleanup, but I'm making a leap that the logs for this are
inadequate, so this needs to be confirmed.
OLD:
            When TCP Pipelining/Session Multiplexing is used, usually by
            Middle boxes today, multiple end user sessions share the same TCP
            connection. Today's network troubleshooter often relies upon
            session decryption to tell which packet belongs to which end
            user.
NEW:
            TCP Pipelining/Session Multiplexing used mainly by middle boxes
            today allow for multiple end user sessions to share the same TCP
            connection. Today's network troubleshooter often relies upon
            session decryption to tell which packet belongs to which end
            user as the logs are currently inadequate for the analysis
            needed.

In HTTP Service Call subsection...
OLD:
            It must
            be possible to match up the user request above with the HTTP
            service call below. Today, this is done by decrypting the TLS
            packet and inspecting the payload.
NEW:
            Troubleshooting via network trace involves matching up the user
            request with the HTTP service call. Some organizations do this
            today by decrypting the TLS packet and inspecting the payload.
            Logging has not been adequate for their purposes.

** Again making the leap that logging has not been adequate for their
purposes and the IETF should be able to help with that in HTTP
standards documentation.

**I am finding I need to replace the text in 4.1.3.4 and this will
need to be reviewed by the contributor.

OLD:
   Modern applications often use XML structures in the payload of the
   data to store application level information.  When the network and
   application teams must work together, each has a different view of
   the transaction failure.  It is important to be able to correlate the
   network packet with the actual problem experienced by an application.
NEW:
            Many applications use text formats such as XML to transport
            data or application level information. When transaction failures
            occur and the logs are inadequate to determine the cause, network
            and application teams work together, each having a different
            view of the transaction failure. Using this troubleshooting
            method, the network packet is correlated with the actual problem
            experienced by an application to find a root cause.  The
            inability to access the payload prevents this method of
            troubleshooting.

- removed 'modern' as other formats have taken over.

>
> - 4.2, 2nd para: A lot of this is duplicative of earlier
> text.

1st paragraph - I think the following needs to be tweaked too.
OLD:
        In some cases, alternate options are available when
        encryption is in use, but techniques like that of data leakage
        prevention tools at a proxy would not be possible if encrypted traffic
        can not be intercepted, thus creating a gap and encouraging alternate
        options.
NEW:
        In some cases, alternate options are available when
        encryption is in use, but techniques like that of data leakage
        prevention tools at a proxy would not be possible if encrypted traffic
        can not be intercepted, encouraging alternate options such as
        performing these functions at the edge.
>
> - 4.2: "unique and efficient vantage point" that's sales
> language and doesn't belong here.

Removed.

>
> - 5.1: "TLS over SMTP" again a couple of times

Ha. fixed.

>
> - 5.2: Is I-D.teague.. the right reference here? I'd have
> thought there was an ipfix RFC already that'd be good here.

This was DOTS and they haven't published anything yet. I removed the
reference as it hasn't been adopted yet and just referred to the WG as
that will have lots more information in time.

>
> - 5.6: "has quickly reacted to" is sales language and doesn't
> belong.

Removed quickly.  Would need to rework the text to change it more.

>
> - 5.6: What is "[not BCP84]" as a reference? And I'm not sure
> why RFC2504 is a good reference here either. Are we talking
> about BCP38 but someone forgot to update text written from
> memory or something? :-)

RFC2827 is BCP 38, so I don't know what was meant by the [not BCP84].
I am guessing the contributor did want both referenced, but I'll
remove the not BCP84 as that's confusing.

>
> - 5.6: SAVI was only chartered for enterprise networks iirc.
>
> - 5.7: THe [SACM] reference is odd and has no entry in
> section 12.

I don't think it's odd as it should help.

>
> - 6.1: Are those "notable exceptions" still relevant? I'd say
> maybe not.

Deleted that sentence, thanks.

>
> - 6.1: Is the Alt-SVC description correct? I'm not sure. I
> suggest you ask an HTTP person maybe. That could also do with
> some references.

*Will have to come back to this one.
>
> - 6.1: "... to be blocked" makes some assumptions about
> what's ok/right that are not needed, "being requested" would
> be better.

I'm deleting the ending clause all together as I think that's clearer
and adding "being requested" isn't the intent.
>
> - section 7: "efforts to prevent it" - which it? And I don't
> think prevent is what you mean, unless you're moving into the
> "what the spooks want" territory and away from "what network
> managers need" which'd seem out of scope.  I think that needs
> rephrasing.

Just deleting the first sentence clears this up as the other 2
sentences cover what was intended well enough.

>
> - section 7: "National surveillance programs" is not the
> right phrase. Maybe just "Law enforcement agencies..."

*Hmm, let's come back to this one.  I'm not sure LEA is right as it's
not the same as a government surveillance program.

>
> - 7: please drop the various uses of "cyber" again;-)
Done. Agreed.

>
> - 7: David Cameron seems to no longer act in that role.

removed.
>
> - 7: "avoid the fears of terrorism" is wrong - fears will
> exiat and be propogated by various actors regardless. And
> understanding technology won't help there. I think the fear
> you mean is that technolgoy will be abused by bad actors.

Changed that part of the first paragraph to address a few of your comments:

NEW:
      Governments vary on their
      balance between their need for monitoring versus the protection
      of user privacy, data, and assets. Those that favor unencrypted
      access to data ignore the real need to protect users
      identity, financial transactions and intellectual property, which
      requires security and encryption to prevent crime. A clear
      understanding of technology, encryption, and monitoring needs will aid
      in the development of solutions to appropriately balance the need of
      privacy. As this understanding increases, hopefully the discussions
      will improve and this draft is meant to help further the discussion.
>
> - 7: The text seems to assume that all governments are
> equally ok and that they all like one another equally. I don't
> believe that is the case, so there are additional categories
> of bad actor that are missing here. I also find the frequency
> of the occurrence of "terror" to be higher than needed. (That
> is a scare-word best omitted when not needed.)

It's there once now as that is the motivator for many of the
surveillance programs.
>
> - 7: I think a reference to the workshop held in Wash. DC
> last year (maybe June?) on whether or not magic solutions for
> LEAs can exist here may be useful. Some IETFers attended, and
> it covered these issues in a lot more depth than could be
> fitted here but I don't have the reference to hand. (Spoiler:
> there is no magic;-)

We are open to contributions!

>
> - 7, last para; I'd recommend deleting this. When and if PIR
> methods are usable they will create as many issues as the
> solve, from the perspective of this document.

I made it less optimistic.  I think if left out, it would become a
talking point that could detract from the purpose of this document.
I'd like it to be clear that this was thought about, but isn't
practical.

>
> - section 11: Is this useful? If not, it ought be deleted.
> If so, then it should be a section of its own on mobile
> networks and not an appendix. (I'll comment assuming that
> keeping the text is better, but I'm not sure it is, given the
> amount of context it may need.)
>
> - 11.1: What is an ACK stream? A reference or description is
> needed. "Prevents" needs justification (possibly via
> reference)
>
> - 11.1: eNodeB needs a reference, KPI/KQI need expansion, CEM
> needs describing or a reference. What is a "sector"?  And (in
> this context) what is "a server"? APN needs a reference.
>
> - 11.1: "trusted parties" is unclear - you need to say what
> is trusted by whom for what actions for this to be useful.
>
> - 11.1: DRM/QOE need expansion and a reference to justify the
> claim wrt *maximising* QOE.
>
> - 11.1: "Trusted proxy" - see above wrt term trusted. But in
> this case, the term is misleading and ought not be used as
> there seems to be no way in which the entity who needs to
> trust the proxy can know that that proxy exists. Please drop
> that term entirely. (Call it a TLS-MitM attacker if you must,
> as that is what it is and that is how such things were
> referred to earlier in this document.) There are two
> occurrences of that misldeading marketing term to remove.
>
> - 11.1: RAN needs expansion and "RAN-aware pacing" needs
> explanation and/or reference.
>
> - 11.2: What is meant here by "Transport header"? TCP mostly
> doesn't have this issue, so I assume this is looking forward
> to QUIC. I'd argue that if so, this text should be deleted as
> we now have a WG for QUIC which is specifically chartered to
> address these issues.  If this is not about QUIC, then please
> elaborate.
>
> - 11.2: ANDSF needs a reference
>
> - 11.2: SON and MLB need references
>
> - 11.2: UPCON needs a reference, off-peak acceleration and
> outbound roamers need explanation and/or reference
>
> - 11.2: DSCP needs a reference
>
> - 11.3: RCS, QCI, LTE need rererences
>
> - 11.3: eMBMS needs a reference, see above wrt "trusted"
>
> - 11.3: Asserting that TLS is not necessary for DRM'd content
> is arguable and not blatently true, as asserted here.
>
> - 11.4: see above wrt "trusted."
>
> - 11.4: QAM, CS-Voice need references
>
> - 11.4: PGW, GGSN need references
>
> - 11.4; "GW" needs explanation and/or a reference
>
> - 11.4: "Decreasing Client-Server control loop requires
> deploying CDNs/Cloud functions that terminate encryption
> closer to the edge." I don't accept that "requires" is
> clearly true. Please justify e.g. via reference. Or maybe
> re-phrase so that the statement is clearly true but doesn't
> have gigantic implications for who is allowed to deploy what.
> (Or maybe I'm confused by what is meant here?)
>
> - 11.4: s/de-encryt/decrypt/
>
> - 11.4: MEC needs a reference, see above wrt "trusted proxy"
>
> - 12.1: I agree with the shepherd that all the references
> here can be informative and you don't need 2119.

Sure, that makes sense.  It is an informative document.

>
> - 12.2: URLs like that used for CAIDA aren't great for RFCs -
> better to find a better reference where that's easy (which it
> is in that case). I'm less sure about how best to deal with
> the Intercept and EFF, but if you search in
> scholar.google.com you may find other references for that
> content that are easier to use. (The issue here being
> reference stability.)

*Yes, I'll have to follow up on this one, but have the URLs in the
current version.  Al and I both knew we would have to fix this later
and should have done it prior to AD review.

>
> - 12.2: [homomophic] needs a better reference if it stays,
> e.g. Gentry's PhD or something.

* Yes, I'll find something.
>
> - 12.2: various references need to be updated. I-D nits will
> help you there

*Yes, I thin there is just one id left and it's actually in my queue
ahead of this document.
>
> - 12.2: I'm sure you'll agree that [TOR] isn't right as-is:-)

*Yes, will fix.
>
>
>

Thanks so much for your review.  Anything with a * is one that either
needs my attention, that of a contributor, or my co-author to go back
and look at.

-- 

Best regards,
Kathleen