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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 09 Nov 2015 08:51:18 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-cdni-logging-21: 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 -21, thanks for the great
improvement in the privacy related stuff. I do however
have one remaining (security related) thing to ask 
about but with a concrete suggested change below.

(1) cleared

(2) cleared

(3) cleared (thanks!)

(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.
I would suggest adding new text in section 3.4 to cover all 
of the log content basically saying that you really need to 
know what you're doing or you can break security very easily. 
Some suggested text that could be added to the end of 3.4 
just before the start of 3.4.1:

"Logging fields from HTTP requests and responses can be
very dangerous. For example, cookies will often contain
(months) long lived bearer token values that can be used
to login to a service as the relevant user. Similar values 
may be included in other header fields or within URLs or
elsewhere in HTTP requests and responses. Centralising
such values in a log can therefore represent a significant
increase in risk both for the user and the web service
provider, but also for the CDNs involved. Implementations 
ought therefore attempt to lower the probability of such 
bad outcomes e.g. by only allowing a configured set of 
headers to be added to logs, or by not supporting wildcard 
selection of HTTP request/response fields to add. Such 
mechanisms can reduce the probability that security (or 
privacy) sensitive values are centralised in logs."

I'm sure that can be improved on, and have no problem with
any specific better words. 

(6) cleared

(7) cleared

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

- in the description of c-groupid, "the address 
with a shared secret that is pre-synchronised
and rotated at a predefined time interval" isn't
very clear. I know what you mean but I don't 
think you state it very clearly. Could be that a
bit of text earlier in the document that describes
the basic idea would be better than doing it all
inline as you have in -21.

OLD COMMENTS Below, not updated for -21, 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: Fri, 13 Nov 2015 12:30:25 -0600

Dear Authors,

> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

Did Stephen's suggestion here work for you?

Thanks,

Spencer

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Sat, 14 Nov 2015 07:14:57 +0000

Hi,

Yes, sorry for the delay.
It is very close to the top of the ToDo list so will get to it soon.

Francois

Sent from my iPhone

On 13 Nov 2015, at 19:30, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

Dear Authors,

On Mon, Nov 9, 2015 at 10:51 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-cdni-logging-21: Discuss

(1) cleared

(2) cleared

(3) cleared (thanks!)

Thanks,

Spencer

(6) cleared

(7) cleared

- 2.2.5.3<http://2.2.5.3>: what's "track audience" mean?

- 2.2.5.4<http://2.2.5.4>: there are more security goals in the universe

- 2.2.5.4<http://2.2.5.4>: seems like the user is the enemy, that's odd

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Sun, 22 Nov 2015 16:57:18 +0000

Hello Stephen.

Thanks for this update to your DISCUSS and COMMENTS.
It all makes sense. Specific responses/resolution discussed below:

That makes sense.

Since the text below is specific to HTTP, I would lean for including it under 3.4.1 ("HTTP Request Logging Record”) rather than under 3.4 which is meant to apply to any log (possibly of other protocols than HTTP).

There is a discussion under 3.4.1 about which fields MUSt be included and which one MAY. I think right after that would be an ideal place to add the text below.

Let me know if that does not work.

"Logging fields

s/Logging fields/Logging some fields/
      since some fields are not very dangerous.

from HTTP requests and responses can be
very dangerous. For example, cookies will often contain
(months) long lived bearer token

This is a bit beyond my expertise, but I wonder if “bearer” is needed here:
s/bearer token/token/  ?
because I think the discussion here is meant to be generic while "bearer token" is a specific form of token.
Or is “bearer token” really the appropriate term in this generic sentence?

values that can be used
such values in a log

s/log/CDNI Logging File/

can therefore represent a significant
increase in risk both for the user and the web service
provider, but also for the CDNs involved. Implementations
ought therefore attempt to lower the probability of such
bad outcomes e.g. by only allowing a configured set of
headers to be added to logs

s/logs/CDNI Logging Records/

, or by not supporting wildcard
selection of HTTP request/response fields to add. Such
mechanisms can reduce the probability that security (or
privacy) sensitive values are centralised in logs.”

s/logs/CDNI Logging Files/

I suggest that , in addition to recommendations for implementations, we also add recommendations for CDN operators:
“Similarly, when agreeing on which HTTP request/response fields are to be provided in CDNI Logging Files, the uCDN and dCDN administrators ought to consider these risks."

(6) cleared

(7) cleared

Right.
We need to do some word tweaking on this anyways, so we’ll try address that.

Those have been addressed in earlier versions.

Here is the message I sent about those back in July in case you want to check the detailed resolution:

From: Francois Le Faucheur <[email-masked]<mailto:[email-masked]>>
Subject: Re: Stephen Farrell's Discuss on draft-ietf-cdni-logging-15: (with DISCUSS and COMMENT)
Date: 19 July 2015 18:39:38 CEST
To: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Cc: Le Faucheur Francois <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Hi Stephen,

Responses to the COMMENT part below:

With anonymization now being a SHOULD, I thought Richard’s DISCUSS was addressed (apart from the potential need to add port anonymization as discussed separately for your own DISCUSS).

Aggregated logs for segmented content is a tricky concept, for which there is no standard today and many potential ways to do it, and which the Working Group has elected to keep for a next version of the logging spec (just so that we can come up with a base CDNI logging spec _relatively_ quickly ).
So the only sure way to support interoperabilty across CDNs for logs of segmented content is to provide per-chunk log, hence the statement that those always need to be generated.

This terminology is likely inherited from the TV/Video era, meaning in particular tracking how big a population watches which movie/video.
Given the more general applicability here, how about we replace by something like “develop statistics on content download”?

Certainly, but this is not a Security Considerations section: section 2.2.5 discussing Log Consuming applications. And 2.2.5.4 is discussing one such application which is to detect violation of content access policy.

With respect to Content Protection (the subject of 2.2.5.4) unauthorised user is indeed the enemy, aiming at stealing some content from the CDNs.

This is fixed in -19 which now says:
"Terminal type (mobile, PC, STB, if this information can be
     acquired from the browser type inferred from the User Agent
     string, for example).
"

As a result of another IESG review comment, we have replaced  our own definition of time by a reference to RFC3339.

“
TIME = 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT]
        ; Times are encoded as "partial-time" specified in [RFC3339].
"

So that point should be fixed already.

Is this just for our information or do you recommend that we add a statement about the fact that cs-uri can be privacy sensitive?
If IP/ports are anonymised, is cs-uri still privacy sensitive (is this in case the uri itself contains some information that can be traced back to a given end-user?

In a per-chunk log (which is specified in this document as the interoperable mechanism to exchange logs for fragmented content), the uri contains the URI of each specific fragment.
In an aggregated log for a segmented content delivery (which is not specified in this document), there are many potential options (URI of first segment, URI of the playlist, part of the URI common to all segments,….). This is one of the complexities of specifying aggregated logs for segmented content.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Nov 2015 17:54:09 +0000

Hiya,

Sure placing the text wherever makes sense if of course
fine,

Cheers,
S