On Wed, Oct 1, 2014 at 11:52 PM, Jim Schaad <[email protected]> wrote:
> > > -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Richard Barnes > Sent: Wednesday, October 01, 2014 7:36 PM > To: The IESG > Cc: [email protected]; > [email protected]; [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
