Re: [CDNi] Super-late Review of draft-ietf-cdni-uri-signing

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

Thanks Matt!

Hi all,

  (as chairs) Per the discussion in the working group session today, we think it makes sense for the authors to look at the possibility of using JWT for the URI Signing token, and at the same time evaluate whether or not it would be easy to pull in the relevant cookie-based transport mechanism from draft-brandenburg-cdni-uri-signing-for-has-03.

  As discussed, there is a trade-off between taking the time to rewrite the token generation portions of the existing WG draft to use JWT and a probable long IESG review cycle for a new security token scheme, as proposed in the current WG draft.  There was general consensus in the room that an existing standard based approach (i.e. JWT) would be the faster approach to document publication -- especially with the help of Matt and Phil.  ;)  We also agreed that it made sense to just rev the existing working group document, rather than submit a separate individual draft.

  If anyone has concerns with the approach described above, please speak up.

thanx!  

--  Kevin and Francois

> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Matt Miller
> (mamille2)
> Sent: Wednesday, July 20, 2016 9:27 AM
> To: [e-mail]
> Subject: [CDNi] Super-late Review of draft-ietf-cdni-uri-signing
> 
> I was asked to review this draft with an eye toward security.
> 
> The short answer: this looks like it's inventing a new crypto container
> and/or
> assertion format, and it would be a smoother path to use existing
> technology.
> 
> Some of the concerns I have are:
> 
> * Implicit algorithms can lead to key substitution attacks if you're not
>   careful.  Ideally the algorithm descriptor should be part of the
> signature/MAC
>   generation; it ought to be part of the primitive, but this is *NOT* true
> of
>   ECDSA nor HMAC.
> * For ECDSA, the curve parameters (named for explicitly) MUST be
> specified, or
>   you run the risk of key substitution attacks.  ECDSA allows a fairly
> large
>   range of curve parameters which can appear to be the same size, and the
>   ASN.1 key format does not require the parameters be present.
> * Encryption without Authentication is strongly discouraged, and ECB is
> the
>   worst of the choices.
> * Mixing hash algorithms have in the past lead to some interesting
>   vulnerabilities.  It's much much better if everywhere hashing is done
>   for a given input/output pair, the same hash algorithm is used.
> * SHA-1 is NOT RECOMMENDED unless it's used in non-cryptographic purposes,
>   but this document in my opinion is still using it for cryptographic
>   purposes in generating the message digest to feed into ECDSA.
> 
> I'll point out that this looks very close to [JWT] in terms of what you're
> trying to
> accomplish.  I am willing to help with text to transform this into a
> profile of JWT.
> 
> 
> --
> - m&m
> 
> Matt Miller
> Cisco Systems, Inc.
> 
> [JWT] JSON Web Token (JWT) < https://tools.ietf.org/html/rfc7519 >