Re: [TLS] Suite B compliance of TLS 1.2
Wan-Teh Chang <wtchang@redhat.com> Wed, 26 July 2006 18:14 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ntg-0004Ap-4b; Wed, 26 Jul 2006 14:14:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nte-0004AU-UK for tls@ietf.org; Wed, 26 Jul 2006 14:14:14 -0400
Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ntb-0000ah-Kz for tls@ietf.org; Wed, 26 Jul 2006 14:14:14 -0400
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6QIEBrX010648 for <tls@ietf.org>; Wed, 26 Jul 2006 14:14:11 -0400
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6QIE5BZ017395 for <tls@ietf.org>; Wed, 26 Jul 2006 14:14:06 -0400
Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k6QIE1cm010730 for <tls@ietf.org>; Wed, 26 Jul 2006 14:14:03 -0400
Message-ID: <44C7B157.70505@redhat.com>
Date: Wed, 26 Jul 2006 11:15:51 -0700
From: Wan-Teh Chang <wtchang@redhat.com>
User-Agent: Thunderbird 2.0a1 (Windows/20060725)
MIME-Version: 1.0
To: tls@ietf.org
Subject: Re: [TLS] Suite B compliance of TLS 1.2
References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com>
In-Reply-To: <86fygpyoir.fsf@raman.networkresonance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
Eric Rescorla wrote: > > I'm not that familiar with Suite B, but if it, as you > say, it doesn't include a MAC algorithm, I'm not sure > what you're suggesting for message integrity. I'm not a cryptographer, so I am struggling with these questions. Option 1: investigate whether HMAC-SHA-1 is still secure and consider HMAC-SHA-256 and HMAC-SHA-384. In NIST Special Publication (SP) 800-57 Part 1 (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf) Table 3 (in Section 5.6.1 on page 64) lists the security strengths of HMAC with various hash functions. It shows that HMAC-SHA-1 may only be used for <= 128 bits of security, and HMAC-SHA-256 may be used for <= 256 bits of security. This would imply that the AES_128 TLS cipher suites may continue to use HMAC-SHA-1 but the AES_256 TLS cipher suites should use HMAC-SHA-256. In his talk "NIST Cryptographic Standards Status Report" at this year's PKI R&D Workshop, Bill Burr of NIST provided some information that helps interpret Table 3 in SP 800-57 Part 1. (http://middleware.internet2.edu/pki06/proceedings/burr-nist_crypto_standards.ppt) Slide 20 says: Federal users [...] may continue to use SHA-1 after 2010 for: - HMAC - Key derivation - Random number generation Slide 30 explains why Suite B uses AES 256 (rather than AES 192) for applications that require 192 bits of security. So in Table 3 we only need to look at the rows for 128 and 192 bits of security for Suite B compliance. Option 2: consider Galois/Counter Mode (GCM) of AES. (http://csrc.nist.gov/publications/drafts.html#sp800-38D) This mode of operation provides message integrity and doesn't use any (general purpose) cryptographic hash function. So GCM seems to avoid the hash function issue altogether, although GCM still uses a keyed hash function called GHASH. TLS could use GCM for both encryption and message integrity (note: the ordering of encryption and MAC'ing is different between GCM and current versions of TLS) or just for message integrity (called GMAC). The TLS working group's web page says: The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. Is GCM the new authenticated encryption mode? Wan-Teh _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Suite B compliance of TLS 1.2 Wan-Teh Chang
- Re: [TLS] Suite B compliance of TLS 1.2 Eric Rescorla
- Re: [TLS] Suite B compliance of TLS 1.2 Martin Rex
- Re: [TLS] Suite B compliance of TLS 1.2 Eric Rescorla
- RE: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri
- Re: [TLS] Suite B compliance of TLS 1.2 Martin Rex
- RE: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri
- Re: [TLS] Suite B compliance of TLS 1.2 Wan-Teh Chang
- Re: [TLS] Suite B compliance of TLS 1.2 Eric Rescorla
- Re: [TLS] Suite B compliance of TLS 1.2 Brian Minard
- Re: [TLS] Suite B compliance of TLS 1.2 Brian Minard
- Re: [TLS] Suite B compliance of TLS 1.2 David Hopwood
- Re: [TLS] Suite B compliance of TLS 1.2 Martin Rex
- RE: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri
- RE: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri
- Re: [TLS] Suite B compliance of TLS 1.2 Eric Rescorla
- RE: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri
- Re: [TLS] Suite B compliance of TLS 1.2 Wan-Teh Chang
- Re: [TLS] Suite B compliance of TLS 1.2 Vipul Gupta