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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 06 Jul 2016 05:10:28 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-cdni-metadata-18: 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-metadata/

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

(1) I don't get the model for telling a dCDN that the user
agent has to have authenticated or that some authorization
is needed before content is to be delivered. Can you
explain?  For example, neither 4.2.5 nor 4.2.7 tell me how
to do anything but allow open-access, and the relevant IANA
registry (section 7.4) is empty, so I'm puzzled. 

(2) 6.5: I think you're missing a MUST in the list here.
I'd suggest something like: "5. Describe the security and
privacy (for the person/user-agent, not only xCDN)
consequences of the extension." I'm assuming that we agree
that it'd be a bad idea if e.g. some extension were defined
that allowed a uCDN tell a dCDN to try to track and report
on all of a user's activities. (Or at least, that'd need to
be documented/justified.)

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

- general: I agree with Ben's discuss about use of TLS. I
also wonder if IPsec is really going to be used here. And
even if so, you might be better off to say that TLS with
mutual-auth SHOULD be used in all cases.

- general: Don't you need some guidance for the dCDN to say
when to stop following (what might be circular) links?

- general: I think it'd be better if the examples given used
https in all cases, assuming we do think that'd be better.
And if it'd not be better, saying why would I think be good.

- 1.2, last para: I don't get what this is saying. What
additional things need specifying? If all you mean is that
the dCDN and uCDN need to be able to setup TLS sessions, and
hence need to agree on what CAs and ciphersuites to use,
then maybe just say that. (You do already refer to RFC7525
so most of that is covered there I think.)

- 4.1.1: I don't think I-JSON requires that order be
preserved, but you seem to need that here, e.g. if a tCDN
decodes and re-encodes, or if a uCDN round-trips a data
structure. Is there a missing "MUST preserve order"
somewhere?

- 4.1.x, 4.2.x, 4.3.x: I wonder if the specification is a
bit too loose in places here, e.g. what does "$$" mean in
4.1.5 and why is that special?  In the same section I also
wasn't clear if "/movies/" is the same as "/movies/*" or
not, nor if you consider that "/movies/*" does or doesn't
match "/movies/1/2/3". Isn't a reference needed in 4.3.4?
I'd guess that a lot of this is close enough that
implementations will likely get a lot, but not all, of this
right, and that that might lead to corner-cases where
interop isn't so good.  Improving that would seem like a
good idea, but perhaps it's better to wait and see what
deployments do and then tidy this up? Not sure.  In reading
I spotted a number of places where such things occurred to
me (but didn't write them all down, sorry;-). 

- 6.8: I didn't follow this, sorry;-) I assume it's
considered clear enough for implementers, so feel free to
ignore me, but I didn't get how to know whether or not e.g.
".v2.2.2" is newer than ".v2" or ".fixed-v1".

- 8.3: did the WG consider (possibly future) uses of JOSE to
provide e2e security from uCDN to dCDN even via tCDN? I'm ok
that you don't define that now, but wondered, as it seems
like a fairly obvious thing to want. (To this security nerd
anyway:-) I also wondered the same for 8.4, but I get that
that'd be less likely of widespread utility. If using IPsec
to security inter-CDN links, something like JOSE would seem
to me to add quite a bit of value, if the CDNs insist on not
using TLS.

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 6 Jul 2016 18:48:50 +0000

Hi Stephen,

  Thanks for the review.

  Wrt your first discuss comment, the intended auth is URI Signing, which is defined in 	
draft-ietf-cdni-uri-signing, and is currently in WGLC.  The idea is that if the content owner or uCDN signed the URI and delivery is delegated to a dCDN, then the dCDN should validate the signing token in the request before responding with the content.  In that case, the dCDN needs to know that it needs to check for a signing token, and what the parameters are for validating the token; this is conveyed in the metadata, along with how to acquire the content.  This task was split into separate documents for various reasons, but we kept the parts that are not URI Signing specific in the metadata draft, so that it's in a centralized place if/when a new auth type is added.

  Wrt your second discuss comment, you make a good point.  I agree that we would (at least) want documentation/justificatio of any intentional security/privacy violating metadata.  We will add the point in the next revision.

  Responses to your other comments inline.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2016 8:10 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with
> DISCUSS and COMMENT)
> 

Yes.  The next revision will have text in line with triggers and logging.

> when to stop following (what might be circular) links?

Good point.  We will review the link text and add loop prevention.

> And if it'd not be better, saying why would I think be good.

Yes.  Ben made the same comment.  This will be updated in the next revision.

> so most of that is covered there I think.)

Yes, CAs and ciphersuites, but there was also the question of keys.  (I suppose if we went with the dCDNs generating their own keys it would be doable?  Or if we left key sharing up to the CDNs to do offline, similar to URI Signing?)
At the time, way back when, some folks looked at it and determined it to be too messy to tackle.
More recently, though I believe you've expressed some skepticism as to the applicability of LURK to CDNI, it seemed like a better option to see what the security experts could come up with, rather than us trying to define a metadata object.

> structure. Is there a missing "MUST preserve order"

We probably should've used the word "array" (which is an ordered list), rather than the word "list"; we will update the text in the next revision.

> me (but didn't write them all down, sorry;-).

The GenArt reviewer also noted the escaped dollar sign "$$" question.  The next revision will try to clarify that text.

> ".v2.2.2" is newer than ".v2" or ".fixed-v1".

We were thinking ".v" + NUM, where comparison is based on NUM, but it probably doesn't actually matter, because the ptype is really opaque to the implementation.  It was more of a suggested convention.

MI.URISigning.v1 will have an RFC associated with it, and has a set of properties defined, and MI.URISigning.v2 will have a different RFC with a whole other set of properties defined (though it may include all of MI.URISigning.v1 by reference).  I don't think it was ever intended that a CDN would need to compare MI.URISigning.v1 and MI.URISigning.v2 for any reason; only that a unique identifier is needed for each (version of a) metadata object, so that one can determine what exactly is supported.  We can try to clean up that text as well.

> to me to add quite a bit of value, if the CDNs insist on not

I do not recall a discussion of JOSE.  It's probably less obvious for us less security-wise.

thanx!

--  Kevin J. Ma

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jul 2016 21:15:23 +0100

Hiya,

On 06/07/16 19:48, Kevin Ma J wrote:
> Hi Stephen,
> 
> Thanks for the review.
> 
> Wrt your first discuss comment, the intended auth is URI Signing,
> which is defined in draft-ietf-cdni-uri-signing, and is currently in
> WGLC.  The idea is that if the content owner or uCDN signed the URI
> and delivery is delegated to a dCDN, then the dCDN should validate
> the signing token in the request before responding with the content.
> In that case, the dCDN needs to know that it needs to check for a
> signing token, and what the parameters are for validating the token;
> this is conveyed in the metadata, along with how to acquire the
> content.  This task was split into separate documents for various
> reasons, but we kept the parts that are not URI Signing specific in
> the metadata draft, so that it's in a centralized place if/when a new
> auth type is added.

Ah grand. A sentence to that effect might help the reader. And it's
ok to add an informative reference to the I-D in question too.

> 
> Wrt your second discuss comment, you make a good point.  I agree that
> we would (at least) want documentation/justificatio of any
> intentional security/privacy violating metadata.  We will add the
> point in the next revision.

Cool. I'll look out for that.

>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Wednesday, July 06, 2016
>> 8:10 AM To: The IESG Cc: [email-masked];
>> [email-masked]; [email-masked]; [email-masked] Subject:
>> Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with 
>> DISCUSS and COMMENT)
>> 
>> 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-metadata/
>> 
>> 
>> 
>> agent has to have authenticated or that some authorization is
>> needed before content is to be delivered. Can you explain?  For
>> example, neither 4.2.5 nor 4.2.7 tell me how to do anything but
>> allow open-access, and the relevant IANA registry (section 7.4) is
>> empty, so I'm puzzled.
>> 
>> (2) 6.5: I think you're missing a MUST in the list here. I'd
>> suggest something like: "5. Describe the security and privacy (for
>> the person/user-agent, not only xCDN) consequences of the
>> extension." I'm assuming that we agree that it'd be a bad idea if
>> e.g. some extension were defined that allowed a uCDN tell a dCDN to
>> try to track and report on all of a user's activities. (Or at
>> least, that'd need to be documented/justified.)
>> 
>> 
>> also wonder if IPsec is really going to be used here. And even if
>> so, you might be better off to say that TLS with mutual-auth SHOULD
>> be used in all cases.
> 
>> - general: Don't you need some guidance for the dCDN to say when to
>> stop following (what might be circular) links?
> 
>> - general: I think it'd be better if the examples given used https
>> in all cases, assuming we do think that'd be better. And if it'd
>> not be better, saying why would I think be good.
> 
>> - 1.2, last para: I don't get what this is saying. What additional
>> things need specifying? If all you mean is that the dCDN and uCDN
>> need to be able to setup TLS sessions, and hence need to agree on
>> what CAs and ciphersuites to use, then maybe just say that. (You do
>> already refer to RFC7525 so most of that is covered there I
>> think.)
> 
> Yes, CAs and ciphersuites, but there was also the question of keys.
> (I suppose if we went with the dCDNs generating their own keys it
> would be doable?  Or if we left key sharing up to the CDNs to do
> offline, similar to URI Signing?) At the time, way back when, some
> folks looked at it and determined it to be too messy to tackle. More
> recently, though I believe you've expressed some skepticism as to the
> applicability of LURK to CDNI, 

Yeah - anything transitive with LURK is very scary. The "L" part
becomes fairly meaningless I reckon. But that's a debate for another
day.

> it seemed like a better option to see
> what the security experts could come up with, rather than us trying
> to define a metadata object.

Anyway, I get what you meant now. But I figure it might be better
to remain silent on this here, and just refer to 7525 for now.

> 
>> - 4.1.1: I don't think I-JSON requires that order be preserved, but
>> you seem to need that here, e.g. if a tCDN decodes and re-encodes,
>> or if a uCDN round-trips a data structure. Is there a missing "MUST
>> preserve order" somewhere?
> 
> We probably should've used the word "array" (which is an ordered
> list), rather than the word "list"; we will update the text in the
> next revision.
> 
>> - 4.1.x, 4.2.x, 4.3.x: I wonder if the specification is a bit too
>> loose in places here, e.g. what does "$$" mean in 4.1.5 and why is
>> that special?  In the same section I also wasn't clear if
>> "/movies/" is the same as "/movies/*" or not, nor if you consider
>> that "/movies/*" does or doesn't match "/movies/1/2/3". Isn't a
>> reference needed in 4.3.4? I'd guess that a lot of this is close
>> enough that implementations will likely get a lot, but not all, of
>> this right, and that that might lead to corner-cases where interop
>> isn't so good.  Improving that would seem like a good idea, but
>> perhaps it's better to wait and see what deployments do and then
>> tidy this up? Not sure.  In reading I spotted a number of places
>> where such things occurred to me (but didn't write them all down,
>> sorry;-).
> 
> The GenArt reviewer also noted the escaped dollar sign "$$" question.
> The next revision will try to clarify that text.

Just to note that I think there are a bunch more (and apologies again
for not documenting 'em all).

All below is fine,
Cheers,
S.

> 
>> - 6.8: I didn't follow this, sorry;-) I assume it's considered
>> clear enough for implementers, so feel free to ignore me, but I
>> didn't get how to know whether or not e.g. ".v2.2.2" is newer than
>> ".v2" or ".fixed-v1".
> 
> We were thinking ".v" + NUM, where comparison is based on NUM, but it
> probably doesn't actually matter, because the ptype is really opaque
> to the implementation.  It was more of a suggested convention.
> 
> MI.URISigning.v1 will have an RFC associated with it, and has a set
> of properties defined, and MI.URISigning.v2 will have a different RFC
> with a whole other set of properties defined (though it may include
> all of MI.URISigning.v1 by reference).  I don't think it was ever
> intended that a CDN would need to compare MI.URISigning.v1 and
> MI.URISigning.v2 for any reason; only that a unique identifier is
> needed for each (version of a) metadata object, so that one can
> determine what exactly is supported.  We can try to clean up that
> text as well.
> 
>> provide e2e security from uCDN to dCDN even via tCDN? I'm ok that
>> you don't define that now, but wondered, as it seems like a fairly
>> obvious thing to want. (To this security nerd anyway:-) I also
>> wondered the same for 8.4, but I get that that'd be less likely of
>> widespread utility. If using IPsec to security inter-CDN links,
>> something like JOSE would seem to me to add quite a bit of value,
>> if the CDNs insist on not using TLS.
>

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 6 Jul 2016 20:38:59 +0000

Hi Stephen,

> ok to add an informative reference to the I-D in question too.
...
> to remain silent on this here, and just refer to 7525 for now.

will do, for both.

thanx!

--  Kevin J. Ma

> Sent: Wednesday, July 06, 2016 4:15 PM
> To: Kevin Ma J; The IESG
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18:
> (with DISCUSS and COMMENT)
> 
> 
> Hiya,
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 8 Jul 2016 01:43:32 +0100

> On 6 Jul 2016, at 21:15, Stephen Farrell <[email-masked]> wrote:

In case it is useful...I was one of the folks Kevin mentions that was worried it was too messy to tackle for a couple of reasons (1) I was worried if we tried to specify some key distribution mechanism we’d come up against lots of resistance from security folks which would bog down progress, and (2) majority of the CDNI use cases I was aware of involved delivering video which was likely to be DRM’d (Nokia’s Velocix CDN product has supported HTTPS for years and I’m not aware of any of our customers delivering video over HTTPS primarily because their content is already DRM’d and they don’t want to pay the performance hit that comes with TLS for already encrypted content).

Ben