Subject: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-logging-19: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 13 Jul 2015 17:33:30 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-cdni-logging-19: Discuss

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-ietf-cdni-logging/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS points updated for -19, I'm not seeing changes
that respond to my discuss points, nor do I recall email
on the topic. (Apologies if I missed some.) I'd be happy to
chat whenever folks are ready.

Let me preface the specific discuss points with an overall
point - I do not think our job here is to force CDNs to behave
well in relation to privacy. However, it is our job to provide
an API that encourages and effectively supports behaving well
in relation to privacy. So, that said...

(1) cleared

(2) 3.3: Thanks for changing from MD5->SHA256 but I 
think you need the format for the SHA256-Hash thing
to be 64HEXDIG don't you?

(3) c-ip-anonymizing: guidance is needed that IPv4 and IPv6
aren't the same here. Why isn't the same idea done for c-port
and other fields?  Has there been any analysis of the
effectiveness of this scheme in not allowing identification or
re-identification? If not, isn't that really needed if we are
serious about defining an API that can protect privacy? If
that was discussed on the list, please send some pointers so I
can get familiar with the work during the discussion.  

(4) cleared (take as part of point (3) if need be) but I 
think you fixed it

(5) I'm not clear why you need to be able to send HTTP header
values or session IDs via this i/f. Why is that needed? (And
it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.)

(6) cleared

(7) This is kind of new, but I'd like to adopt Richard's 
DISCUSS so that doesn't get lost and it's very related to
my point (3) too and I previously noted that I supported
him. So that was:
"I'm concerned that the information model of this log format encourages
the
sharing of far more granular information than is justified by the use
cases. 
All of the use cases in Section 2 are focused on statistical information,
in
which case collecting things like individual IP addresses and ports is
unnecessary."

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

OLD COMMENTS Below, not updated for -18, I didn't
check if you took 'em on board, feel free to chat about
'em if that's useful  - I'm happy to do so anyway.

- I support Richard's discuss. Isn't it ironic that the dCDN's
privacy (that of a company) is better supported than that of
the end user (a person) 

- 2.2.1 - why is per-chunk always needed? 

- 2.2.5.3: what's "track audience" mean?

- 2.2.5.4: there are more security goals in the universe

- 2.2.5.4: seems like the user is the enemy, that's odd

- 2.2.5.6.2: there is no "browser type header" that I know of,
but there is the well-known UA string. Being specific about
that is better.

- 3.1: SS.S - does that imply a time granularity of 100ms?  If
so, please say so.

- 3.4.4: cs-uri: please not that these can be privacy
sensitive, though presumably less so than e.g.  logged URIs on
a search engine.

- 3.4.4: foo-uri: do these contain fragments or not?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 18 Jul 2015 22:16:52 +0200

Just FYI to the CDNI folk, I've talked with Barry, and I'll continue to be
the shepherding AD for this document because I know the history.

Do we need to talk this coming week? I know we'd all like to finish this
draft off ...

Thanks,

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 19 Jul 2015 07:55:49 +0100

They already mailed me and I arranged to meet 'em Monday for lunch.
I do agree a chat would be good.

S.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Sun, 19 Jul 2015 15:47:08 +0000

Hi Stephen,

Below are responses to your DISCUSS, in view of converging as much as possible before we meet on Monday:

(I’ll try do teh same for the COMMENT part)

(1) cleared

Yes. It is already changed to 64HEXDIG.
But I checked thoughout and it had not been changed in the examples of CDNI Logging Files( in Fig 4, Fig 5 and Fig 6). So we’ll fix that.

aren't the same here.

The following text had been included in the document:
“
The mechanism by which the two ends of the
         CDNI Logging interface agree on whether anonymization is to be
         supported and the number of bits that need to be zeroed-out for
         this purpose are outside the scope of the present document.
         IPv4 addresses SHOULD be anonymized to /24 boundary (i.e., with
         c-ip-anonymizing set to 8), and IPv6 addresses SHOULD be
         anonymized to a /48 boundary (i.e., with c-ip-anonymizing set
         to 80).
“
Is that alright?
If not, any suggestions on how to further improve?

Why isn't the same idea done for c-port
and other fields?  Has there been any analysis of the
effectiveness of this scheme in not allowing identification or
re-identification? If not, isn't that really needed if we are
serious about defining an API that can protect privacy?

We don’t really have anyone involved yet with great privacy expertise.
A naive question to start with, if the IP address is anonymised, why is it necessary to also anonymize the port?
We can easily add port anonymization if that is useful, so if you feel there is a need for that, let us know and we’ll add that.
Would masking of rightmost bits also be teh right anonymization mechanism for port numbers?

If

I believe HTTP Headers are routinely logged in CDNs today, and a functionality we need to preserve across CDNs.
The W3C Extended Log Format (http://www.w3.org/pub/WWW/TR/WD-logfile-960323.html) includes the ability to log HTTP Headers.
HTTP headers are used in logs for various purposes. One example is statistics (say on browser types).

(6) cleared

unnecessary.”

There has been some discussion about that with Richard (I think). As a result:

1)  anomyzation has been elevated to a “SHOULD”:
IPv4 addresses SHOULD be anonymized to /24 boundary (i.e., with
         c-ip-anonymizing set to 8), and IPv6 addresses SHOULD be
         anonymized to a /48 boundary (i.e., with c-ip-anonymizing set
         to 80).

and

2) the following text in section 2.2.5.1:
“
Some of these maintenance and debugging applications only require
   aggregate logging information highly compatible with anonymization of
   IP addresses (as supported by the present document and specified in
   Section 3.4.1).  However, in some situations, it may be useful, where
   compatible with privacy protection, to access some CDNI Logging
   Records containing full non-anonymized IP addresses.  For example,
   this may be useful for detailed fault tracking of a particular end
   user content delivery issue.
“

Does that not address the concern appropriately?

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 21 Jul 2015 13:37:31 +0000

Stephen and all,

Here are my notes on what was agreed during Monday meeting with Stephen (+Spencer & Pete) as the next steps regarding handling of privacy in cdni-logging:

1) CDNI Design Team:
* a design team wil be established focusing on privacy for CDNI logging
* design team will be responsible for assessing in a short timeframe whether it is feasible to come up with an approach/solution/recommendation for privacy-friendly CDNI logging, and in what timeframe.
 * in particular, it will consider mechanisms that already exist in IETF (eg RFC 6235) and whether/how they can improve privacy-protection
* design team will comprise members from CDNI Working Group + 1 or two “privacy/security” experts that will be identified by Stephen.
* based on the design team conclusions, WG + IESG will decide how to progress cdni-logging wrt privacy.

2) Aggregated Logs
* CDNI WG will be polled to establish whether there is interest/energy to work on aggregated CDNI log records (which could help in increasing privacy protection)

Please comment/correct if not accurate.

For information, here is my informal summary of the outcomes of the CDNI WG meeting regarding the above points:

Regarding 1):
* the CDNI WG has identified CDNI participants for the Design Team (Iuniana Oprescu, Kevin Ma, Ray van Brandenburg)
* the CDNI WG established a timeframe of 4 weeks, after establishment of the full Design Team membership, to come up with first conclusions
* we now need the security/privacy experts to be identifed so the work can start (Stephen, the ball is in your camp).

Regarding 2):
* When prompted, noone in the room expressed interest in working on agregated logs at this stage. Concerns were expressed that Aggregated Log would make analytics limited/useless. Concerns were experessed that this may not solve the privacy concerns anyway. Some expressed opinion that privacy concerns were not justified (mostly because this information is routinely gathered today and exchanged between CDNs and Content Providers), some expressed opinion that privacy concerns cannot be addressed until they are described better.

Francois

On 19 Jul 2015, at 17:47, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stephen,

(1) cleared

If

(6) cleared

and

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jul 2015 14:57:39 +0100

Hiya,

On 21/07/15 14:37, Francois Le Faucheur (flefauch) wrote:
> * we now need the security/privacy experts to be identifed so the
> work can start (Stephen, the ball is in your camp).

In-work. I think I have one willing person, and am waiting on
an ana 2nd.

> 
> Regarding 2): * When prompted, noone in the room expressed interest
> in working on agregated logs at this stage. Concerns were expressed
> that Aggregated Log would make analytics limited/useless. 

Yes, I get that concern and believe it is the major reason why the
WG aren't interested. Is that fair?

> Concerns
> were experessed that this may not solve the privacy concerns anyway.

Huh? Of course nothing will "solve" privacy concerns in a 100%
pure manner, but that is not what's suggested. It seems entirely
clear to me at least that reporting information about batches
of 1000's of user is far more efficient and privacy-friendly. It
would require transmission and storage of far far less data that
is far far less sensitive. (The potentially largest cost of that
data is that one ends up storing it, since it may leak.)

> Some expressed opinion that privacy concerns were not justified
> (mostly because this information is routinely gathered today and
> exchanged between CDNs and Content Providers), 

Well, two things. First the fact that something privacy unfriendly
is done today just does not logically mean that doing that tomorrow
is ok. When changes are needed, sometimes those have impacts. And
secondly, if CDNI has value, it will extend the reach and availability
of this data, and thus the logging done will have broader scope and
be more privacy sensitive, so standardising this is in fact not at
all the same as what is done today in the absence of CDNI.

> some expressed opinion
> that privacy concerns cannot be addressed until they are described
> better.

Honestly? Sorry but that seems utterly unbelievable. The potential
privacy issues with defining an interface that allows for even more
centralisation of HTTP logs should be blindingly obvious.

Are we saying that there are some CDNI participants who in fact
don't care about the privacy impact of this data, because they
make money from serving that data? If so, then I think it would be
better to say just that.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jul 2015 14:58:57 +0100

> In-work. I think I have one willing person, and am waiting on

Sorry, typo. I'm waiting on an answer from a 2nd.

S

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 21 Jul 2015 14:05:06 +0000

Hi Stephen,

Thanks for your answer. We’ll stay tuned for the experts.

I will not attempt to represent the various WG participants viewpoints. It was shared for information. I will defer to the Design Team to continue that discussion in detail and report their conclusion.

Cheers

Francois

> On 21 Jul 2015, at 15:57, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 21 Jul 2015 15:02:17 +0000

Hi Stephen,

> all the same as what is done today in the absence of CDNI.
...
> centralisation of HTTP logs should be blindingly obvious.

I think one of the questions was:

Assuming the request came to the uCDN, and the uCDN redirects the request to a dCDN, then both the uCDN and dCDN have received the request from the client, and both have the same private information that those requests contain.  In that case, information shared back in the log is information that both CDNs already have.  Given that, I have a couple of clarifying questions:

1. Is the concern that if the LI is compromised, then a third-party may get that information?

2. Or is the concern than the CDNs may be storing this information at all?

The former seems like it could be addressed without aggregation (e.g., using anonymization)?

Addressing the latter seems a bit more ambitious; requiring aggregation does not necessarily change how/what data is stored in the CDN?

> make money from serving that data? If so, then I think it would be

I'm sure there are people who make money by parsing the data; the data has valuable (non-nefarious) uses.  However, I think the question was more along the lines of the two questions raised above, e.g.:

1. If the transmission of the data is encrypted and authenticated, or even if the data itself was independently encrypted, does/would that suffice?  If so, then would aggregation still be necessary?  Furthermore, if the data was better anonymized, would that make aggregation unnecessary?  Or is aggregation always necessary to provide maximum privacy?

2. Designing an aggregation scheme that still supports all of the various analytics scenarios users have/want today is likely a rather large task.  Taking more time to design a better protocol is not necessarily a bad thing, but, time is money, even if CDN log data is not.  ;)

I think it will be helpful once we have the privacy experts input into the design team, so that we can better understand what the exact issues are that we need to address, and the actual value of the proposed solutions.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, July 21, 2015 9:58 AM
> To: Francois Le Faucheur (flefauch)
> Cc: [email-masked]; The IESG; [email-masked]; cdni-
> [email-masked]
> Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-logging-
> 19: (with DISCUSS and COMMENT)
> 
> 
> Hiya,
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni