Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

Martin Rex <mrex@sap.com> Mon, 22 February 2010 15:39 UTC

Return-Path: <mrex@sap.com>
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 942D928C294 for <tls@core3.amsl.com>; Mon, 22 Feb 2010 07:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.222
X-Spam-Level:
X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 bCzaIpYs6A7k for <tls@core3.amsl.com>; Mon, 22 Feb 2010 07:39:36 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 71EC128C1D8 for <tls@ietf.org>; Mon, 22 Feb 2010 07:39:35 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o1MFfTsg023895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 16:41:29 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201002221541.o1MFfSBu007590@fs4113.wdf.sap.corp>
To: simon@josefsson.org (Simon Josefsson)
Date: Mon, 22 Feb 2010 16:41:28 +0100 (MET)
In-Reply-To: <87k4u5zn01.fsf@mocca.josefsson.org> from "Simon Josefsson" at Feb 22, 10 09:35:26 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: DPKemp@missi.ncsc.mil, tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@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-Archive: <http://www.ietf.org/mail-archive/web/tls>
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>
X-List-Received-Date: Mon, 22 Feb 2010 15:39:37 -0000

Simon Josefsson wrote:
> 
> Brian Smith <brian@briansmith.org>; writes:
> 
> > 1. As long as this web page on the NIST website says, basically,
> > "don't use SHA-1 for anything," people will want to disable SHA-1
> > whenever they can. It doesn't matter that this page on the website
> > isn't the official NIST recommendation on the matter.
> 
> I'd like to suggest another argument to support your reasoning: some
> FIPS approved crypto libraries no longer export MD5.  I expect the same
> to be true for SHA-1 within a few years.  This means that SHA-1 will no
> longer be as easily available, for these non-crypto purposes needed in
> tls-cached-info.

I do not agree to this conclusion.  IIRC, NIST never liked MD5 from
the beginning, and it was always clear about that, which is why
SHA-1 as an alternative became ubiquitous available everywhere where
a secure hash algorithm was needed.

While it seems sensible to deprecate SHA-1 for use in digital
signatures, it is still present in many certs and many signatures.
Even last year, some PKIs have been newly set up with a hierarchy
of CAs using SHA-1 for the signature on the intermediate CA and
end entity certs--probably because the SHA-2 algorithm is not
yet universally available in implementations.

If you look at the mandatory-to-implement algorithm for SSLv3 and
TLS up to v1.2 (rfc5246):

  TLSv1.0 (rfc-2246, section 9)  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  TLSv1.1 (rfc-4346, section 9)  TLS_RSA_WITH_3DES_EDE_CBC_SHA
  TLSv1.2 (rfc-5246, section 9)  TLS_RSA_WITH_AES_128_CBC_SHA
  
So getting rid of SHA-1 will require a significantly larger effort
than getting rid of MD5 (-based signatures).

> 
> Chosing SHA-256 will give us more time, but we'll likely run into the
> same issue eventually anyway.  I believe this suggests that algorithm
> agility is useful whenever any crypto-related algorithm is _used_, even
> if it is used for non-crypto related purposes.


TLS truncates the PRF output to 12 octets for the finished message.
Maybe we should truncate the hash for the caching extension to
20 octets (which means that sha-1 hash values are sent in full)?


-Martin