Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The Transport

Martin Rex <Martin.Rex@sap.com> Tue, 11 March 2008 14:36 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: ietfarch-tls-archive@core3.amsl.com
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0123F3A6E28; Tue, 11 Mar 2008 07:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.23
X-Spam-Level:
X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoZo2aCScME1; Tue, 11 Mar 2008 07:35:55 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA18328C4A5; Tue, 11 Mar 2008 07:35:49 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079CC28C47A for <tls@core3.amsl.com>; Tue, 11 Mar 2008 07:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnWueRcSufSq for <tls@core3.amsl.com>; Tue, 11 Mar 2008 07:35:43 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 1A2763A67A3 for <tls@ietf.org>; Tue, 11 Mar 2008 07:35:08 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id m2BEVqs4003507; Tue, 11 Mar 2008 15:32:05 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200803111431.m2BEVp9k023120@fs4113.wdf.sap.corp>
To: martin.rex@sap.com
Date: Tue, 11 Mar 2008 15:31:51 +0100
In-Reply-To: <200803101856.m2AIuNJf011412@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 10, 8 07:56:23 pm
MIME-Version: 1.0
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The Transport
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Martin Rex wrote:
> 
> Rob Williams wrote:
> > 
> > Just as SHA-224 is to SHA-256, 
> >         SHA-384 is to SHA-512: truncated with different IV.
> > 
> > I am looking forward to seeing SHA-384 removed from TLS 1.2.
> 
> The difference between sha-256, sha-384 and sha-512 is much larger,
> and while the effort for calculating sha-384 and sha-512 might
> be the same, the resource consumption on keypair and digital signature
> generation for/with the DSA algorithm might make a hash with a
> size between 256 and 512 bit attractive.

I found an strange statement in FIPS-180-2 (with SHA-224 change notice)
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

This is from the SHA-224 change notice on page 73 of above document,
in a section titled "Truncation of the Hash Function Output":

   Truncated hash output shall not be used in place of the full hash
   output by standardized applications that reference this Standard,
   e.g. digital signatures (FIPS 186-2) or keyed hash functions used
   for message authentication (FIPS 198).

I'm just not sure what it exactly means:
Does it mean that neither SHA-224 nor SHA-384 should be used in
digital signatures?  To me, this appears to be implied.

I don't see a reason why truncations that are given specific names
(such as SHA-224 and SHA-384) should not be considered truncations.

On the other hand, the statement about truncation of keyed hash
functions used for message authentication appears confused me.
IPsec does truncation on purpose, but this statement in FIPS-180-2+
appears to suggest this is a bad idea (and not FIPS-compliant...)


So does someone know what this all means (and can translate it
from FIPS into English language)?

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls