Re: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-signing

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

Hi Ray,

> > [Ray] In the end, I wouldn’t be surprised if some
> > implementations actually only implemented KID_NUM.
>
> Are there any guidelines on mandatory to
> support/implement IEs?  Is one allowed to only implement KID_NUM and not
> KID
>
> [Ray] Currently, we don’t have any such guidelines and an implementation
> is expected to implement all IEs (but _not_ all algorithms).

So, if I send KID=1234 (instead of KID_NUM=1234), we would expect every implementation to support this?  And if I send KID=abcd, we would expect every implementation to support that as well?  If so, then I see no point in having KID_NUM.

> Ben’s
> suggestion to not make DSA mandatory does not sound unreasonable to me.

Then, I still think you need an error code for this in the logging, and a MUST statement about rejecting requests with algorithms you don't support.

> [Ray] It seems we agree that folding HF and DSA into one information
> element wouldn’t fundamentally remove steps from the algorithm itself, nor
> reduce it’s complexity.

true

> Then I still don’t see the downside of having both
> an HF and DSA information element, especially if it means we do not have
> to add a registry and it makes the step of checking which steps of the
> algorithm you need to follow easier.

But you already have a registry (section 8.7) just for MD and DS?  That seems even less useful.  I'd argue that a registry of known/supported algorithms is better than a registry just for those two IEs.  If a new signature algorithm is added, is someone expected to add another IE to the "CDNI URI Signing Signature Information Elements" registry?

> If you’re concerned about the wording
> in the paragraphs above, wouldn’t it be easier if I would simply replace
> the ‘symmetric’ and ‘assymetric’ in the paragraphs above with ‘if HF is
> present’ and ‘if DSA is present’?

I'm concerned about the complexity of the parser.  Granted it doesn't make it that much more complex, but a generic IE, imo, is simpler than multiple IEs, where one would work just fine.  Same with KID and KID_NUM.  The extra IEs are just more cases to handle, for marginal value if any, imo.

If no one else cares, that's fine, but since Ben brought it up, I wanted to renew my previous comments.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> Sent: Tuesday, July 12, 2016 7:48 AM
> To: Kevin Ma J; Ben Niven-Jenkins; Content Delivery Networks
> Interconnection Discussion List
> Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-signing
> 
> Hi Kevin,
> 
> On 11/07/16 16:56, "Kevin Ma J" <[e-mail]> wrote:
> 
> Hi Ray,
> 
> > Given that Leif and his colleagues actually implemented the algorithm,
> and
> > they were the ones asking for this change, my guess would be yes. But
> > let’s ask them to make sure.
> 
>   I believe Leif and Phil agreed in BA to re-review during WGLC, so,
> hopefully they can chime in.  :)
> 
> > In the end, I wouldn’t be surprised if some
> > implementations actually only implemented KID_NUM.
> 
>   Thinking about this some more.  Are there any guidelines on mandatory to
> support/implement IEs?  Is one allowed to only implement KID_NUM and not
> KID, or only HF/MD and not DSA/DS; and if an IE is not supported, is there
> a MUST reject?  If so, should there be an error code for that?
> 
> [Ray] Currently, we don’t have any such guidelines and an implementation
> is expected to implement all IEs (but _not_ all algorithms). Ben’s
> suggestion to not make DSA mandatory does not sound unreasonable to me.
> 
> > If you look at the algorithm, the paths for HF and DSA are considerably
> > different.
> 
> Just to take it one step further: Yes, the algorithms are different, but
> in section 3.2, steps 1 and 2 clearly state "1. If symmetric shared key is
> use, perform this step" and "2. if asymmetric private/public keys are
> used, perform this step".  The difference is already broken out. The only
> difference to the current text would be a find/replace on the IE in those
> sections.  Likewise, in section 4.4, steps 2.A and 2.B are separated based
> on whether the algorithm is symmetric or asymmetric, as determined in
> section 4.2, steps 2 and 3.  (Note: Section 4.3 would actually be
> simplified by not having to distinguish between MD/DS.)  The only real
> question, imo, is whether or not section 4.2, steps 2 and 3 could be
> replaced with an algorithm check rather than an IE check, i.e., if SHA256,
> then it's symmetric, else if ECDSA, then it's asymmetric?
> 
> There currently isn't a registry for supported HF/SAs.
>   1. Would a registry make sense?
>   2. Would a registry with a clear/obvious designation of symmetric vs
> asymmetric make the above test easy?
> 
> [Ray] It seems we agree that folding HF and DSA into one information
> element wouldn’t fundamentally remove steps from the algorithm itself, nor
> reduce it’s complexity. Then I still don’t see the downside of having both
> an HF and DSA information element, especially if it means we do not have
> to add a registry and it makes the step of checking which steps of the
> algorithm you need to follow easier. If you’re concerned about the wording
> in the paragraphs above, wouldn’t it be easier if I would simply replace
> the ‘symmetric’ and ‘assymetric’ in the paragraphs above with ‘if HF is
> present’ and ‘if DSA is present’?
> 
> Also, I've proposed removal of the Metadata Auth Type registry from the
> metadata draft; if that is accepted, we would no longer need section 8.4
> 
> [Ray] Ok.
> 
> thanx!
> 
> --  Kevin J. Ma
> 
> > -----Original Message-----
> > From: Brandenburg, R. (Ray) van [mailto:[e-mail]]
> > Sent: Monday, July 11, 2016 3:28 AM
> > To: Kevin Ma J; Ben Niven-Jenkins; Content Delivery Networks
> > Interconnection Discussion List
> > Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-
> signing
> >
> > Hi Kevin,
> >
> >  > 1. Having both KID and KID_NUM seems unnecessary to me.  I understand
> > Leif's argument
> >
> (https://mailarchive.ietf.org/arch/msg/cdni/YDIrOdutbrvQkEwvAevwONdiUFE),
> > but I'm still not sure I agree.  Are implementers really going to have 2
> > separate code paths, one with an integer variable and another with a
> > string variable, just to get a memory efficiency?  Or is the integer
> just
> > going to get converted to a string?  And they already have to allocate
> the
> > memory just to parse the token?
> >
> > Given that Leif and his colleagues actually implemented the algorithm,
> and
> > they were the ones asking for this change, my guess would be yes. But
> > let’s ask them to make sure. In the end, I wouldn’t be surprised if some
> > implementations actually only implemented KID_NUM.
> >
> > >  2. I agree that having both HF and DSA could be unnecessary.  I know
> > we've also had long discussions about needing for both MD and DS.
> > Ultimately, there is an algorithm (HF or DSA) that is run, and results
> in
> > a signature (MD or DS), and only one pair (HF/MD or DSA/DS) ends up in
> the
> > token?  The algorithm doesn't really change dramatically if the IE's are
> > different?  Is it just about readability?
> >
> > If you look at the algorithm, the paths for HF and DSA are considerably
> > different. One performs an HMAC as defined by HF, the other does a
> > (keyless) SHA-1 hash, then encrypts the result with an encryption
> > function. If we would merge both into a single Information Element
> (let’s
> > call it Signature Algorithm, or SA, for now), the algorithm would have
> to
> > include something along the lines of: “If the algorithm communicated in
> > the SA field is a Digital Signature Algorithm, perform X. If it is a
> > hashing function, perform Y.”. In other words, the two different paths
> in
> > the algorithm will keep existing, but now you’re probably going to have
> to
> > give some definition or list of which algorithms classify as Digital
> > Signature Algorithm and which as hashing functions. In the end, I’m not
> > sure what we would gain by it.
> >
> > Thanks,
> >
> > Ray
> >
> >
> > On 08/07/16 23:19, "Kevin Ma J" <[e-mail]> wrote:
> >
> > Hi Ray,
> >
> >   (As an individual) I'll echo two of Ben's points, as I've asked
> similar
> > questions in the past:
> >
> >   1. Having both KID and KID_NUM seems unnecessary to me.  I understand
> > Leif's argument
> >
> (https://mailarchive.ietf.org/arch/msg/cdni/YDIrOdutbrvQkEwvAevwONdiUFE),
> > but I'm still not sure I agree.  Are implementers really going to have 2
> > separate code paths, one with an integer variable and another with a
> > string variable, just to get a memory efficiency?  Or is the integer
> just
> > going to get converted to a string?  And they already have to allocate
> the
> > memory just to parse the token?
> >
> >   2. I agree that having both HF and DSA could be unnecessary.  I know
> > we've also had long discussions about needing for both MD and DS.
> > Ultimately, there is an algorithm (HF or DSA) that is run, and results
> in
> > a signature (MD or DS), and only one pair (HF/MD or DSA/DS) ends up in
> the
> > token?  The algorithm doesn't really change dramatically if the IE's are
> > different?  Is it just about readability?
> >
> > thanx!
> >
> > --  Kevin J. Ma
> >
> > > -----Original Message-----
> > > From: CDNi [mailto:[e-mail]] On Behalf Of Brandenburg, R.
> > > (Ray) van
> > > Sent: Friday, July 08, 2016 7:12 AM
> > > To: Ben Niven-Jenkins; Content Delivery Networks Interconnection
> > > Discussion List
> > > Subject: Re: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-
> > signing
> > >
> > > Hi Ben,
> > >
> > > Thanks for the thorough review! See my comments below.
> > >
> > > Ray
> > >
> > > On 02/07/16 13:35, "CDNi on behalf of Ben Niven-Jenkins" <cdni-
> > > [e-mail] on behalf of [e-mail]> wrote:
> > >
> > > Kevin, Colleagues,
> > >
> > > I reviewed draft-ietf-cdni-uri-signing-09 & below are my comments.
> > >
> > > General:
> > >
> > > The document is not clear on whether implementers are expected to
> > > implement both shared secret & digital signature algorithms for signed
> > URI
> > > validation. This could lead to interop problems where different
> > > implementation implement one but not the other.
> > >
> > > Maybe specify a minimum baseline of MUST support shared secret (as
> AFAIK
> > > that is what is used in the field) with SHOULD implement digital
> > > signatures for the 1 corner case for which digital signatures provide
> an
> > > advantage.
> > >
> > > I’m somewhat against specifying must implement both shared secret &
> > > digital signatures because I’ve never seen a digital signature based
> > > signed URI in the field and I’m familiar with quite a few signed URI
> > > algorithms/implementations of different CDNs. That says to me folks
> are
> > > not likely to implement more than the shared secret algorithm unless
> > they
> > > really need to. I know Cisco have a digital signature implementation
> > maybe
> > > they could help with how much use it sees in the field?
> > >
> > > [Ray] Agreed that we shouldn’t make digital signatures mandatory. As
> for
> > > making support for shared secrets mandatory: I guess that makes sense.
> > >
> > > The document could do with some more examples of {URI, attributes,
> > > URISigningPackage, Signed URI} covering e.g. IPv4 & IPv6, one
> including
> > a
> > > URI Path Pattern etc.
> > >
> > > Section 2.1:
> > > URI Pattern Container (UPC) definition - how does one represent a URI
> > > pattern that contains a literal ‘;’ because the URI/URI pattern
> contains
> > > in path parameters to match against? Does presence of a literal ‘;’
> need
> > > to be escaped with ‘$' too to distinguish it from the use of ‘;’ to
> > > separate URI patterns within the URI Pattern Container?
> > >
> > > [Ray] Good point. Literal semi-colons do indeed need to be escaped.
> I’ll
> > > add this in the next revision
> > >
> > > Section 2.2:
> > > Why is there a KID (string) & KID_NUM (integer) for shared
> secrets/keys
> > > and only CKI (integer) for Client IP keys? To be consistent should it
> be
> > > CKI_NUM?
> > >
> > > The document also says
> > >    In cases
> > >    where numerical KEY IDs are used, it is RECOMMENDED to use KID_NUM
> > >    instead of KID.
> > > Which makes me think, why? What the KID means/represents is
> communicated
> > > out of band (and how to do that is out of scope of the document). It
> > seems
> > > straightforward to say KID is always a string (which can represent an
> > > integer) and get rid of KID_NUM entirely. That would mean we need one
> > less
> > > attribute defining (or two less if we need string & integer attributes
> > for
> > > CKI) and avoids folks having to work out what to do & implement corner
> > > cases like what to do if KID & KID_NUM are both present.
> > >
> > > Why not just have KID and CKI both as strings and remove KID_NUM?
> > >
> > > [Ray] This was the consensus result of a lengthy discussion between
> the
> > > authors both on and off list ☺ The main reason we included a string-
> > based
> > > KID was so that we can have URLs to public keys. However, as Leif
> > pointed
> > > out, for interop and performance reasons it helps to have maximum
> length
> > > for the KID field. With public keys this is hard to do. So in cases
> > where
> > > performance is essential, using a fixed-length int field is faster.
> The
> > > reason we didn’t extend this to the CKI field is that for CKI we only
> > > support symmetric encryption, and hence a integer key index should be
> > > sufficient.
> > >
> > > Along similar lines. Why have both HF & DSA. Is it implicit from the
> > value
> > > of the attribute (e.g. 'SHA-256' vs ‘ECDSA’) whether a shared secret
> or
> > > digital signature algorithm is being used? Or is the purpose to enable
> > URI
> > > to be signed (& subsequently) verified with either (if both are
> > specified)
> > > or with both?
> > >
> > > [Ray] We explicitly rule out having both HF and DSA information
> elements
> > > in a single Signed URI. The reason we went for separate IEs is that it
> > > makes describing the algorithm slightly less complex. And given that
> we
> > > base64-encode the full URI Signing Package anyway it doesn’t really
> > matter
> > > in terms of namespace collisions.
> > >
> > > Section 3.1:
> > > 8)a) says
> > >            Note: the Original URI
> > >            Container information element MUST be the last information
> > >            element in the buffer before the signature information
> > >            element.
> > > 8)b) does not have a similar statement. Is the URI Pattern Container
> > also
> > > required (MUST) to be the last information element in the buffer?
> > >
> > > [Ray] The Original URI Container is a special case in the sense that
> it
> > > isn’t communicated along with the Signed URI but is removed from the
> > > package after having calculated the signature.
> > >
> > > Section 5.4:
> > > I don’t see the point of key-id, hash-function, digital-signature-
> > > algorithm & version.
> > >
> > > The absence of the VER attribute is specified by the document to mean
> > > Version 1. The absence of the HF & DSA attributes is specified by the
> > > version of the signing method. Version 1 (the document) specifies them
> > as
> > > SHA-256 & ECDSA accordingly. Why re-specify this in the Metadata
> object?
> > >
> > > [Ray] I’m not sure I understand. What the metadata ‘version’ field is
> > for
> > > is to allow CDNs to mandate other versions of URI Signing in the
> future
> > > (e.g. by setting the version property to 2). The same goes for the
> hash-
> > > function and digital-signature-algorithm properties: a CDN could
> mandate
> > > that URI Signing version 1 is used, but still only allow SHA-512
> instead
> > > of SHA-256 as used by default.
> > >
> > > key-id is for when there is only a single key id as an optimisation if
> > > someone wants to have a single key id & not transmit it in the signed
> > URI?
> > > Does;t seem worth it to me for a narrow corner case. If it is worth it
> > > just specify if KID/KID_NUM is missing from the signed URI and key-id-
> > set
> > > contains a single value then use that? Or if KID/KID_NUM is missing
> the
> > > surrogate checks all keys in key-id-set and if one matches the URI is
> > > authorised?
> > >
> > > [Ray] See earlier comment
> > >
> > > (Personally I think KID/KID_NUM in the Signed URi is pointless, their
> > > meaning is distributed out of band so why not also distribute the
> values
> > > out of band/via metadata and have the behaviour be any valid
> key/secret
> > in
> > > key-id-set passes and remove KID/KID_NUM [and maybe CKI] from the
> Signed
> > > URI entirely)
> > >
> > > [Ray] I’m not sure I understand. How would the dCDN know which Key is
> > used
> > > to calculate a given signature? Or are you saying it should just check
> > all
> > > possible Keys that are in the allowed set?
> > >
> > > Section 5.4:
> > > This confused me:
> > >    Note that the Key ID information element is not needed if only one
> > >    key is provided by the CSP or the Upstream CDN for the content item
> > >    or set of content items covered by the CDNI Metadata object.
> > > until I realised that “Key ID information element” was referring to
> the
> > > element of the Signed URI and not the key-id property of the metadata
> > > object specified immediately above the sentence. Maybe phrase as “Note
> > > that the Key ID information element does not need to be included in
> the
> > > Signed URI if only one key…"
> > >
> > > [Ray] Good point. Will update.
> > >
> > > Section 9:
> > >    In the case where asymmetric keys are used, the KID information
> > >    element might contain the URL to the public key.  To prevent
> > >    malicious clients from signing their own URIs and inserting the
> > >    associated public key URL in the KID field, thereby passing URI
> > >    validation, it is important that CDNs check whether the URI
> conveyed
> > >    in the KID field is in the allowable set of KIDs as listed in the
> > >    CDNI metadata or set via configuration.
> > > Or specify things as I suggest above and remove the need for
> KID/KID_NUM
> > > being present in the Signed URI and therefore this
> > scenario/vulnerability
> > > being able to occur in the first place?
> > >
> > > [Ray] See my earlier comment. I don’t see how the dCDN would ever be
> > able
> > > to know which key was used. But maybe I’m missing something.
> > >
> > > nits:
> > > Section 1:
> > >    The primary goal of URI Signing is to make
> > >    sure that only authorized User Agents (UAs) are able to access the
> > >    content, with a CSP being able to authorize every individual
> request.
> > > Is it really to authorise the User Agent or the IP address the User
> > Agent
> > > is behind? There is nothing in the signed URI that identifies the
> > > particular User Agent. URIs can still potentially be shared/exchanged
> > > between User Agents behind the same IP address/subnet, however the
> > impact
> > > of such sharing is limited/acceptable for the use case.
> > >
> > > I would s/User Agents (UAs)/IP address(es)/
> > >
> > > Section 1:
> > > I do not know what is meant by distribution policy in this sentence:
> > >    Splitting the role of performing per-request
> > >    authorization by CSP and the role of validation of this
> authorization
> > >    by the CDN allows any arbitrary distribution policy to be enforced
> > >    across CDNs without the need of CDNs to have any awareness of the
> > >    actual CSP distribution policy.
> > >
> > > Section 2.2:
> > >    The Key ID Information Element is used to retrieved the key which
> is
> > >    needed as input to the algorithm for validating the Signed URI.
> > > s/retrieved/retrieve/
> > >
> > > Section 2.4:
> > >    However, a client or CDN may append other
> > >    query parameters unrelated to URI Signing to the Signed URI.  Such
> > >    additional query parameters SHOULD NOT use the same name as the URI
> > >    Signing Package Attribute to avoid namespace collision and
> potential
> > >    failure of the URI Signing validation.
> > > s/client/User Agent/ is probably more aligned with the rest of the
> > > document. There are some other places where you use client. Probably
> > worth
> > > being consistent and picking one of client or User Agent to use
> > > throughout.
> > >
> > > Section 3:
> > >    In case the
> > >    URI Pattern Container information element is used, the CSP has full
> > >    flexibility to specify which elements of the URI (including the
> > >    scheme part) are protected by the URI.
> > > I think you mean “protected by the Signed URI”?
> > >
> > > Section 3:
> > >    The process of generating a Signed URI can be divided into four
> sets
> > >    of steps: 1) Compose URI Signing IEs with original URI / URI
> pattern,
> > >    2) Compute the URI Signature, 3) Encode the URI Signing Package,
> and
> > >    4) Assemble the parts to create the Signed URI.
> > > This would be better as a list of numbered bullets IMO.
> > >
> > >
> > > [Ray] Thanks again!
> > >
> > > HTH
> > > Ben
> > >
> > > > On 29 Jun 2016, at 14:43, Kevin Ma J <[e-mail]>
> wrote:
> > > >
> > > > Hi All,
> > > >
> > > >  As per the discussion in BA, we have received the updated URI
> Signing
> > > draft and would like to move it to WGLC.  (Leif and Phil, you're up!)
> > > >
> > > >  Today will begin the two-week WGLC on:
> > > https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-09
> > > >
> > > >  Please send any comments, questions, concerns to the CDNI mailing
> > list:
> > > [e-mail]
> > > >
> > > >  The WGLC will end on Wednesday July 13, 2016.
> > > >
> > > > thanx!
> > > >
> > > > --  Kevin and Francois
> > > >
> > > > _______________________________________________
> > > > CDNi mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/cdni
> > >
> > > _______________________________________________
> > > CDNi mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/cdni
> > >
> > >
> > > This message may contain information that is not intended for you. If
> > you
> > > are not the addressee or if this message was sent to you by mistake,
> you
> > > are requested to inform the sender and delete the message. TNO accepts
> > no
> > > liability for the content of this e-mail, for the manner in which you
> > use
> > > it and for damage of any kind resulting from the risks inherent to the
> > > electronic transmission of messages.
> > > _______________________________________________
> > > CDNi mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/cdni
> >
> >
> > This message may contain information that is not intended for you. If
> you
> > are not the addressee or if this message was sent to you by mistake, you
> > are requested to inform the sender and delete the message. TNO accepts
> no
> > liability for the content of this e-mail, for the manner in which you
> use
> > it and for damage of any kind resulting from the risks inherent to the
> > electronic transmission of messages.
> 
> 
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.