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

[Stephen Farrell <[e-mail]>]

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
>