Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

On Wed, Oct 1, 2014 at 11:52 PM, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
> -----Original Message-----
> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
> Sent: Wednesday, October 01, 2014 7:36 PM
> To: The IESG
> Cc: jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-algorithms@tools.ietf.org; jose@ietf.org
> Subject: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-jose-json-web-algorithms-33: 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 3.2.
> "This computed HMAC value is then compared to the result of base64url
> decoding the received encoded JWS Signature value."
> Need to add:
> "In order to avoid timing attacks, the comparison of the computed HMAC
> value
> to the JWS Signature value MUST be done in a constant-time manner."
>
> Section 3.6.
> I'm not going to object to "none", even though I think it's a very
> dangerous
> feature because of the risk of confusion between Secured and Unsecured JWS.
> But there needs to be stronger guidance:
> 1. An implementation SHOULD NOT support "none" unless the implementor knows
> that it will be used in application context s that require it.
> 2. If an implementation does support "none", then it MUST NOT accept it as
> part of generic JWS validation.  Instead, it should require the application
> to explicitly signal that an Unsecured JWS is expected for a given
> validation operation.
>
> Section 4.2.
> Systems that support RSAES-PKCS1-V1_5 key unwrap are commonly vulnerable to
> oracle attacks based on whether they accept the wrapped key or not.
> See, e.g.,
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431
> http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/
> In light of that, it seems irresponsible to include this algorithm without
> extensive security precautions, and especially irresponsible for it to be
> REQUIRED.  It's been dropped from WebCrypto, and is being dropped from TLS
> in v1.3.
>
> Section 6.3.1.
> The descriptions of these parameters are really vague, especially when it
> comes to the "oth" parameters.  Please cite a reference that provides more
> detail, e.g., RFC 3447.
>
> Section 6.3.2.6.
> This section defines the wrong parameter.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1.1.
> The pointer for BASE64URL should be to JWS.  One level of indirection,
> please :)
>
> Section 3.1, 4.1, and 5.1.
> As I said in the working group, the implementation requirements in these
> registries should be removed.  They are unnecessary for interoperability,
> and highly likely to be ignored by implementors, both because (1) many
> implementations are for specific applications that do not require all of
> the
> REQUIRED algorithms, and (2) many implementations use cryptographic
> libraries that do not support some REQUIRED algorithms.  I have personally
> written more than one JWS/JWE implementation that ignored these
> requirements, for exactly these reasons.  (This would be a DISCUSS for me,
> if not for my having made this argument already in the WG.)
>
> Section 3.2.
> "A key of the same size as the hash output (for instance, 256 bits for
> "HS256") or larger MUST be used with this algorithm."
> A pointer to Section 3 of RFC 2104 here would be helpful.  I was surprised
> at this requirement, given that FIPS 198 says "The size of the key, K,
> shall
> be equal to or greater than L/2, where L is the size of the hash function
> output."
>
> [JLS] This does not seem to be the statement in sp800-107 rev1 (section
> 5.3.4) which updated FIPS 198.   It says that the security = min (length of
> K, 2*C) where C is the internal barrel length.
>

Ah, OK.  Thanks for the updated reference.  I stand corrected.

--Richard

>
> Section 3.4.
> It might be worth noting that though this format seems ad-hoc, it is the
> same used by WebCrypto.
>
> Section 4.7.1.1.
> Shouldn't you require that this field MUST encode a 16-octet / 128-bit
> value?
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>