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

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 2 Jul 2016 12:35:52 +0100

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?

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?

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?

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?

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?

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?

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?

(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)

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…"

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?

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.

HTH
Ben

> On 29 Jun 2016, at 14:43, Kevin Ma J <[email-masked]> 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: [email-masked]
> 
>  The WGLC will end on Wednesday July 13, 2016.
> 
> thanx!
> 
> --  Kevin and Francois
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 8 Jul 2016 11:11:53 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

Kevin, Colleagues,

General:

[Ray] Agreed that we shouldn’t make digital signatures mandatory. As for making support for shared secrets mandatory: I guess that makes sense. 

Section 2.1:

[Ray] Good point. Literal semi-colons do indeed need to be escaped. I’ll add this in the next revision

Section 2.2:

The document also says
   In cases

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

[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

[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:

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

[Ray] See earlier comment

[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:

[Ray] Good point. Will update. 

Section 9:

[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:

Section 1:

Section 2.2:

Section 2.4:

Section 3:
   In case the

Section 3:

[Ray] Thanks again!

HTH
Ben

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.

---

From: Kevin Ma J <[email-masked]>
Date: Fri, 8 Jul 2016 21:19:30 +0000

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:[email-masked]] 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,
> 
> On 02/07/16 13:35, "CDNi on behalf of Ben Niven-Jenkins" <cdni-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> Kevin, Colleagues,
> 
> 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?
> 
> 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
> 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.
> 
> [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
> 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:
> 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?
> 
> (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:
> 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…"
> 
> 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:
> 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.
> 
> 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
> >  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
> >
> 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.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 11 Jul 2016 07:27:57 +0000

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…

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, a…

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" <[email-masked]> wrote:

Hi Ray,

thanx!

--  Kevin J. Ma

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 11 Jul 2016 14:56:48 +0000

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?

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

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

thanx!

--  Kevin J. Ma

> From: Brandenburg, R. (Ray) van [mailto:[email-masked]]
> Sent: Monday, July 11, 2016 3:28 AM
> To: Kevin Ma J; Ben Niven-Jenkins; Content Delivery Networks
> Interconnection Discussion List
>  > 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
> 
> 
>   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
> 
> > >  Please send any comments, questions, concerns to the CDNI mailing
> list:
> > [email-masked]
> > >

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 12 Jul 2016 11:48:26 +0000

Hi Kevin,

On 11/07/16 16:56, "Kevin Ma J" <[email-masked]> wrote:

Hi Ray,

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

[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’? 

[Ray] Ok.

thanx!

--  Kevin J. Ma

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 12 Jul 2016 14:06:48 +0000

Hi Ray,

> > [Ray] In the end, I wouldn’t be surprised if some
> 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

> Sent: Tuesday, July 12, 2016 7:48 AM
>   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.
> 
> 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?
> 
> [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
> 
> >   (As an individual) I'll echo two of Ben's points, as I've asked
> similar
> > questions in the past:
> >
> > > URISigningPackage, Signed URI} covering e.g. IPv4 & IPv6, one
> including
> > a
> > > URI Path Pattern etc.
> > >
> > > Section 2.1:
> > > [Ray] Good point. Literal semi-colons do indeed need to be escaped.
> I’ll
> > > add this in the next revision
> > >
> > > Section 2.2:
> > > out of band/via metadata and have the behaviour be any valid
> key/secret
> > in

---

From: Leif Hedstrom <[email-masked]>
Date: Fri, 15 Jul 2016 09:54:24 -0600

> On Jul 12, 2016, at 8:06 AM, Kevin Ma J <[email-masked]> wrote:
> 
> Hi Ray,
> 

The discussion around KID_NUM actually predates the introduction of the package attribute. Since we now require (I think?) the packaging, the benefits of the KID_NUM is somewhat diminished. You’ll have to allocate the full memory to unpack the entire package anyways.

KID_NUM also has the benefit of well specified semantics, e.g. you could use a vector instead of a hash for lookups. I don’t know how important that is, but it certainly could have some benefits for performance. I do care about performance, because a valid use case of URI signing is DoS prevention.

I’m +0 on removing KID_NUM, as in, I can live with it being collapsed into just KID with no semantics (“free text”).

I’m planning on reviewing -09 this weekend, before the Berlin meeting.

Cheers,

— leif

---

From: Kevin Ma J <[email-masked]>
Date: Fri, 15 Jul 2016 16:24:46 +0000

Hi Leif,

  Thanks for the response.  I think it makes sense to extend the WGLC, to make sure we have time for you and Phil to review and the WG to discuss any comments.

  The WGLC was scheduled to end on July 13; we will extend it two weeks, until after IETF96, and end the WGLC on July 27th.

thanx!

--  Kevin and Francois

> From: Leif Hedstrom [mailto:[email-masked]]
> Sent: Friday, July 15, 2016 11:54 AM
> To: Kevin Ma J
> Cc: Brandenburg, R. (Ray) van; Ben Niven-Jenkins; Content Delivery
> Networks Interconnection Discussion List
> > 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.
> 
> 
> The discussion around KID_NUM actually predates the introduction of the
> package attribute. Since we now require (I think?) the packaging, the
> benefits of the KID_NUM is somewhat diminished. You’ll have to allocate
> the full memory to unpack the entire package anyways.
> 
> KID_NUM also has the benefit of well specified semantics, e.g. you could
> use a vector instead of a hash for lookups. I don’t know how important
> that is, but it certainly could have some benefits for performance. I do
> care about performance, because a valid use case of URI signing is DoS
> prevention.
> 
> I’m +0 on removing KID_NUM, as in, I can live with it being collapsed into
> just KID with no semantics (“free text”).
>

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 20 Jul 2016 14:25:16 +0000

Hi all,

  (as chairs) Based on the discussions in the working group session today, we are ending the WGLC on draft-ietf-cdni-uri-signing-09 and will wait for a new version of the document from the authors in the early September timeframe.  (Please see the other email wrt Matt Miller's comments on draft-ietf-cdni-uri-signing-09.)

thanx!

--  Kevin and Francois

> From: Kevin Ma J
> Sent: Friday, July 15, 2016 12:27 PM
> To: 'Leif Hedstrom'
> Subject: RE: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-signing
> 
> Hi Leif,
> 
>   Thanks for the response.  I think it makes sense to extend the WGLC, to
> make sure we have time for you and Phil to review and the WG to discuss
> any comments.
> 
>   The WGLC was scheduled to end on July 13; we will extend it two weeks,
> until after IETF96, and end the WGLC on July 27th.
> 
> thanx!
> 
> --  Kevin and Francois
...
> From: Kevin Ma J
> Sent: Wednesday, June 29, 2016 9:45 AM
> To: [email-masked]
> Subject: Working Group Last Call on draft-ietf-cdni-uri-signing
> 
> Hi All,
>