[Cfrg] What Algorithm information needs to be authenticated?
"Jim Schaad" <ietf@augustcellars.com> Thu, 04 April 2013 06:26 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D393C21F95F4 for <cfrg@ietfa.amsl.com>; Wed, 3 Apr 2013 23:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 I20t+l1bXhQj for <cfrg@ietfa.amsl.com>; Wed, 3 Apr 2013 23:26:21 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A28BB21F95F0 for <cfrg@irtf.org>; Wed, 3 Apr 2013 23:26:21 -0700 (PDT)
Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 11ACE38EA7 for <cfrg@irtf.org>; Wed, 3 Apr 2013 23:26:21 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: cfrg@irtf.org
Date: Wed, 03 Apr 2013 23:25:44 -0700
Message-ID: <00ac01ce30fd$3d373350$b7a599f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4w8b10meAP4tSuRQOj77FabgFZww==
Content-Language: en-us
Subject: [Cfrg] What Algorithm information needs to be authenticated?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 06:26:23 -0000
Request for Information The JOSE working group is having an internal argument about the need to protect the various header information in an encrypted or signed message. The quick question is which algorithm information and algorithm parameters need to be included in integrity portion of the signature or encryption operation in order to protect those parameters. There are a couple of theoretical attacks that can be launched against various algorithms that then require protection an example of such a parameter is the IV for the AES-CBC/HMAC algorithm that has been proposed. In this case the IV is protected by the algorithm itself and therefore does not need to be externally protected by the JOSE data structures. In RFC 6211, there is a new CMS attribute that was defined for protection of the signature algorithm as I felt there was a potential attack that could be exploited. Looking at the RSA v1.5 signature algorithm, one cannot change the hash algorithm as the hash algorithm is encoded as part of the padding for the signature Looking at the RSA PSS signature, there is the possibility that a hash algorithm of the same length could be substituted unless external restrictions are applied. Thus one could potentially substitute a RIPEMD-160 hash on the content for a SHA-1 hash. As long as the hashes match and there is no externally applied restriction that the hash algorithm used to build the PSS internals is same as the content hash then it would verify. It is unclear if there is an attack that involves multiple hash algorithms that is better than a birthday attack on a single algorithm as I don't know if this has ever been studied. CMS also defined an attribute that can be included in the signature computation for specifying a certificate that is to be used in the validation of the signature on the CMS object. I.e. where to get the public key and the base restrictions for that are imposed on that public key by the certificate issuer. Questions that we would like to see discussed: 1. For signature operations, what parameters related to the signature algorithm and what parameters related to a key need to be protected by the signature operation to prevent real and theoretical attacks on JOSE signed structures. We would like to get the real and theoretical attacks separated with a weight on the theoretical attacks for the potential to become real. 2. For MAC operations, what parameters related to the MAC algorithm and what parameters related to the key need to be protected by the MAC operation to prevent real and theoretical attacks on a JOSE MAC structure. 3. For key management operations (how the content encryption key is given to the recipient), what parameters related to the algorithms need to be protected as part of the AEAD algorithm. 4. For content encryption, what parameter related to the AEAD algorithm need to be protected by the AEAD algorithm (and are not already protected) need to be included. Is there any benefit in double protecting parameters such as the IV in case a new AEAD algorithm does not directly protect that value. Looking at the key to be protected, we don't care if the recipient cannot find the correct key or misinterprets what the key identifier is. What we want to make sure is that an attacker would be unable to change the recipients interpretation of what key is to be used and still get a successful validation. Jim Schaad JOSE Co-Chair
- [Cfrg] What Algorithm information needs to be aut… Jim Schaad
- Re: [Cfrg] What Algorithm information needs to be… Igoe, Kevin M.
- Re: [Cfrg] What Algorithm information needs to be… Jim Schaad
- Re: [Cfrg] What Algorithm information needs to be… Igoe, Kevin M.
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… Ben Laurie
- Re: [Cfrg] What Algorithm information needs to be… Ben Laurie
- Re: [Cfrg] What Algorithm information needs to be… Mike Jones
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… Ben Laurie
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… John Bradley
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… John Bradley
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… Ben Laurie
- Re: [Cfrg] What Algorithm information needs to be… Ben Laurie
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… Richard Barnes
- Re: [Cfrg] What Algorithm information needs to be… Ben Laurie
- Re: [Cfrg] What Algorithm information needs to be… Blumenthal, Uri - 0558 - MITLL