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

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 20 Jul 2016 13:26:47 +0000

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 >

---

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

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:[email-masked]] On Behalf Of Matt Miller
> (mamille2)
> Sent: Wednesday, July 20, 2016 9:27 AM
> To: [email-masked]
> Subject: [CDNi] Super-late Review of draft-ietf-cdni-uri-signing
>