[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