[jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption
David McGrew <mcgrew@cisco.com> Tue, 15 November 2011 12:40 UTC
Return-Path: <mcgrew@cisco.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821711E8125 for <jose@ietfa.amsl.com>; Tue, 15 Nov 2011 04:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.049
X-Spam-Level:
X-Spam-Status: No, score=-106.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsNzW3-U5hNT for <jose@ietfa.amsl.com>; Tue, 15 Nov 2011 04:40:14 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 476E411E811F for <jose@ietf.org>; Tue, 15 Nov 2011 04:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=4103; q=dns/txt; s=iport; t=1321360814; x=1322570414; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date; bh=lFh3knzOz19gCHqexNbbpeu0qesWWc3COlycxZeaSRQ=; b=SD5eHKfzSo5pZ1t3HfUz++Lt69L0SZvlreXT6H9h5SIvq7CWAfP+jjgm 34gOX7yrzvx9waks7kFrTjrR6mT6nk785TVq7Hpxe6xIMBxyBV3YuXI9y VTcnIH9j7GIhD68FrhrHA+0Ae6JMGtA1kgXB4U/qNYHniHeC/JBTG/+dC c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIxcwk6rRDoH/2dsb2JhbABDhQGkbIEFggsBEAQRMEYCJgKBFKFHgSYBjFmSMIEwh0szYwSIE4wfhTuMYA
X-IronPort-AV: E=Sophos;i="4.69,514,1315180800"; d="scan'208";a="14316355"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 15 Nov 2011 12:40:14 +0000
Received: from [10.32.254.210] ([10.32.254.210]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAFCeDla006432 for <jose@ietf.org>; Tue, 15 Nov 2011 12:40:13 GMT
Message-Id: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: jose@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 15 Nov 2011 04:40:12 -0800
X-Mailer: Apple Mail (2.936)
X-Mailman-Approved-At: Tue, 15 Nov 2011 04:52:58 -0800
Subject: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Tue, 15 Nov 2011 12:40:15 -0000
Hi I would like to contribute the following comments. I have not been closely following the WG, so apologies in advance if I'm rehashing something. The json-web-signature draft should be changed by using the more generic "authentication" instead of "signature", as suggested in Section 9. HMAC is a (symmetric) message authentication code, and not an (asymmetric) digital signature algorithm. See RFC 4949 for instance for the appropriate definitions. Calling HMAC a signature method will confuse readers going forward and potentially set incorrect expectations. I suggest the following changes (not because I think these are the only good alternatives, but because I want to be constructive): "JSON Web Signature" -> "JSON Web Authentication" "sign" -> "authenticate" "signing" -> "authenticating" "signature" -> "authentication data" The security considerations of json-web-signature should explain the difference between symmetric and asymmetric encryption. Section 9 mentions the possibility of including an unkeyed checksum based on SHA-256. If that is done, then that will potentially confuse the issue further. What would the value of that checksum be, and would it be a security mechanism? If it is defined, I suggest that it be done in a different draft. Why are we allowing unauthenticated encryption in draft-jones-json-web- encryption? Authenticated Encryption with Associated Data (AEAD) is recommended (in the form of AES-GCM) in the draft, and it avoids all sorts of security issues that are present with unauthenticated encryption (besides being theoretically vulnerable, it has fallen victim to practical attacks [1][2][3][4][5][6][7][8]). Note that some of these attacks apply when encryption is loosely bound to authentication. I suggest that AEAD be the only encryption method, and that an RFC 5116 interface be included. Since GCM is recommended, the interface is already there, but not called out. Omitting unauthenticated encryption will simplify the spec, and improve security. If there is some percieved issue with AES-GCM, there are other AEAD algorithms that can be used, AES-SIV (synthetic IV mode) for instance, or a generic CBC+HMAC composition. In any case, I offer to help craft and/or review this text. A minor point: JWE recommends AES-GCM; why not have json-web-signature recommend AES-GMAC? json-web-signature says that "Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification". The JWE specification says that "In general, senders SHOULD sign the message and then encrypt the result (thus encrypting the signature)". There ought to be better recommendations for security. For instance, encryption without authentication should be disallowed. regards, David -- [1] Vaudenay, "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002. [2] Rizzo, Duong, "Practical Padding Oracle Attacks", Black Hat Europe, 2010. [3] Jager, Somorovsky, "How To Break XML Encryption", 18th ACM Conference on Computer and Communications Security (CCS), 2011. [4] Bellare, Kohno, Namprempre, "Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then- Encrypt-and-MAC paradigm", ACM Transactions on Information and System Security, May 2004. [5] Rizzo, Thai, "BEAST: Surprising crypto attack against HTTPS", Ekoparty, 2011. [6] Bellovin, “Problem Areas for the IP Security Protocols”, Sixth Usenix Unix Security Symposium, 1996. [7] Paterson, Yau, “Cryptography in theory and practice: The case of encryption in IPsec”, EUROCRYPT 2006, [8] Degabriele, Paterson, "Attacking the IPsec Standards in Encryption- only Configurations", IEEE Symposium on Security and Privacy, 2007.
- [jose] comments on draft-jones-json-web-signature… David McGrew
- Re: [jose] comments on draft-jones-json-web-signa… Anthony Nadalin
- Re: [jose] comments on draft-jones-json-web-signa… Mike Jones
- Re: [jose] comments on draft-jones-json-web-signa… Nat Sakimura
- Re: [jose] comments on draft-jones-json-web-signa… David McGrew
- Re: [jose] comments on draft-jones-json-web-signa… Nat Sakimura
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jeremy Laurenson (jlaurens)
- Re: [jose] comments on draft-jones-json-web-signa… Phillip Hallam-Baker
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… Mike Jones
- Re: [jose] comments on draft-jones-json-web-signa… Leif Johansson
- Re: [jose] comments on draft-jones-json-web-signa… Matthew Green
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… John Bradley
- Re: [jose] comments on draft-jones-json-web-signa… Jim Schaad
- Re: [jose] comments on draft-jones-json-web-signa… Matthew Green