[jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
"Richard Barnes" <rlb@ipv.sx> Thu, 02 October 2014 02:36 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE631A0016; Wed, 1 Oct 2014 19:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1CYzlTJLJaV; Wed, 1 Oct 2014 19:36:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8662B1A0012; Wed, 1 Oct 2014 19:36:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Richard Barnes <rlb@ipv.sx>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141002023617.18602.69709.idtracker@ietfa.amsl.com>
Date: Wed, 01 Oct 2014 19:36:17 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/249eEll2qOEZMdwi60gUlTnasS0
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)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Oct 2014 02:36:20 -0000
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." 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] Richard Barnes' Discuss on draft-ietf-jose… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Brian Campbell
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Kathleen Moriarty
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes