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