IETF Logo Mail Archive

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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Fri, 19 February 2010 17:57 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 58B0628C2E7 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 09:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 hip-lZ9rjKIW for <tls@core3.amsl.com>; Fri, 19 Feb 2010 09:57:45 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 635B628C2DF for <tls@ietf.org>; Fri, 19 Feb 2010 09:57:45 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB18D.435A3238"
Date: Fri, 19 Feb 2010 12:59:20 -0500
Message-ID: <201002191759.o1JHxWij019709@stingray.missi.ncsc.mil>
In-Reply-To: <4B7EC4D1.5070006@briansmith.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
Thread-Index: AcqxhcVnPwHX2EQWTiug/TUBqANa3wAAZiMQ
References: <201002191403.o1JE3qWe004203@fs4113.wdf.sap.corp> <4B7EA8E7.3050703@briansmith.org> <201002191538.o1JFcqh4005438@stingray.missi.ncsc.mil> <4B7EC4D1.5070006@briansmith.org>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 19 Feb 2010 18:00:17.0640 (UTC) FILETIME=[64FEB680:01CAB18D]
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
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: Fri, 19 Feb 2010 17:57:46 -0000

As Stefan pointed out, MUST support does not equal MUST use.  If you or your customers cannot be convinced that the NIST guidance is irrelevant to cache item tagging, then your implementation can certainly support SHA-2.  It is even “legal” (in an RFC 2119 sense) for your customers to configure your application to refuse to use SHA-1 if they believe that is necessary to comply with NIST guidance, as long as other customers (guided by appropriate documentation and common sense) are able to configure it to use SHA-1.

 

I oppose removing a requirement to MUST support a common algorithm.   And I would oppose making the common algorithm SHA-2 because that is moving in the wrong direction for saving bytes:  a single uint32 is sufficient; more (SHA-1) is excessive, and much more (SHA-2) is much more excessive.   This applies equally whether the server pre-calculates an opaque token and sends it to the client or the client and server each calculate the token interoperably.

 

Dave

 

 

From: Brian Smith [mailto:brian@briansmith.org] 
Sent: Friday, February 19, 2010 12:05 PM



And, I am definitely not convinced that all users/customers will be convinced, so I would rather be safe than sorry.

Perhaps this all can be avoided by simply not having the client calculate hashes at all.

…

It is strongly recommended that the server use a secure hash algorithm (e.g. SHA-2) of the value as the token.

v2.23.0 | Report a Bug | By Email