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

[Kevin Ma J <[e-mail]>]

Hi Stephen,

> 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.
...
> 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.

will do, for both.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Wednesday, July 06, 2016 4:15 PM
> To: Kevin Ma J; The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18:
> (with DISCUSS and COMMENT)
> 
> 
> 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.
> 
> >
> > Responses to your other comments inline.
> >
> > thanx!
> >
> > --  Kevin J. Ma
> >
> >> -----Original Message----- From: Stephen Farrell
> >> [mailto:[e-mail]] Sent: Wednesday, July 06, 2016
> >> 8:10 AM To: The IESG Cc: [e-mail];
> >> [e-mail]; [e-mail]; [e-mail] Subject:
> >> Stephen Farrell's Discuss on draft-ietf-cdni-metadata-18: (with
> >> DISCUSS and COMMENT)
> >>
> >> 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.
> >
> > Yes.  The next revision will have text in line with triggers and
> > logging.
> >
> >> - general: Don't you need some guidance for the dCDN to say when to
> >> stop following (what might be circular) links?
> >
> > Good point.  We will review the link text and add loop prevention.
> >
> >> - 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.
> >
> > Yes.  Ben made the same comment.  This will be updated in the next
> > revision.
> >
> >> - 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.
> >
> >> - 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.
> >
> > I do not recall a discussion of JOSE.  It's probably less obvious for
> > us less security-wise.
> >
> > thanx!
> >
> > --  Kevin J. Ma
> >