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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Francois,

On Jan 27, 2016 10:53, "Francois Le Faucheur (flefauch)" <[e-mail]>
wrote:
>
> Hello Spencer,
>
> I should be able to work on this next week.
> Thanks for the reminder.

That works for me.

Spencer

> Francois
>
>
>> On 26 Jan 2016, at 04:00, Spencer Dawkins at IETF <
[e-mail]> wrote:
>>
>> Hi, Francois,
>>
>> On Sun, Nov 22, 2015 at 11:54 AM, Stephen Farrell <
[e-mail]> wrote:
>>>
>>>
>>> Hiya,
>>>
>>> Sure placing the text wherever makes sense if of course
>>> fine,
>>>
>>> Cheers,
>>> S
>>>
>>> On 22/11/15 16:57, Francois Le Faucheur (flefauch) wrote:
>>> > Hello Stephen.
>>> >
>>> > Thanks for this update to your DISCUSS and COMMENTS.
>>> > It all makes sense. Specific responses/resolution discussed below:
>>
>>
>> If I'm following this correctly, you and Stephen have closed on
resolutions for his DISCUSS and COMMENTS.
>>
>> Could you let me know when I should expect a revised draft?
>>
>> I would love to finish this up.
>>
>> Thanks!
>>
>> Spencer
>>
>>>
>>> > (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.
>>> >
>>> > That makes sense.
>>> >
>>> > Some suggested text that could be added to the end of 3.4
>>> > just before the start of 3.4.1:
>>> >
>>> > 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
>>> > 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
>>> >
>>> > 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."
>>> >
>>> >
>>> >
>>> > 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.
>>> >
>>> > Right.
>>> > We need to do some word tweaking on this anyways, so we’ll try
address that.
>>> >
>>> >
>>> > 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.
>>> >
>>> > 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 <[e-mail]<mailto:
[e-mail]>>
>>> > 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 <[e-mail]<mailto:
[e-mail]>>
>>> > Cc: Le Faucheur Francois <[e-mail]<mailto:[e-mail]>>,
The IESG <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:
[e-mail]>, [e-mail]<mailto:
[e-mail]>
>>> >
>>> > Hi Stephen,
>>> >
>>> > Responses to the COMMENT part below:
>>> >
>>> >
>>> >
>>> > ----------------------------------------------------------------------
>>> > COMMENT:
>>> > ----------------------------------------------------------------------
>>> >
>>> >
>>> > - 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)
>>> >
>>> > 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).
>>> >
>>> >
>>> > - 2.2.1 - why is per-chunk always needed?
>>> >
>>> > 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.
>>> >
>>> >
>>> >
>>> > - 2.2.5.3: what's "track audience" mean?
>>> >
>>> > 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”?
>>> >
>>> >
>>> > - 2.2.5.4: there are more security goals in the universe
>>> >
>>> > 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.
>>> >
>>> >
>>> > - 2.2.5.4: seems like the user is the enemy, that's odd
>>> >
>>> > 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.
>>> >
>>> >
>>> > - 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.
>>> >
>>> > 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).
>>> > "
>>> >
>>> > - 3.1: SS.S - does that imply a time granularity of 100ms?  If
>>> > so, please say so.
>>> >
>>> > 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.
>>> >
>>> >
>>> >
>>> > - 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.
>>> >
>>> > 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?
>>> >
>>> >
>>> >
>>> > - 3.4.4: foo-uri: do these contain fragments or not?
>>> >
>>> > 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.
>>> >
>>> >
>>> >
>>> >
>>> > - 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?
>>> >
>>> >
>>> >
>>>
>>
>