Re: [TLS] Suite B compliance of TLS 1.2

David Hopwood <david.nospam.hopwood@blueyonder.co.uk> Wed, 26 July 2006 20:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5plm-0000zU-BN; Wed, 26 Jul 2006 16:14:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5plk-0000zO-Dm for tls@ietf.org; Wed, 26 Jul 2006 16:14:12 -0400
Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5plj-00051z-2g for tls@ietf.org; Wed, 26 Jul 2006 16:14:12 -0400
Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1G5ple-0006RQ-Ox for tls@ietf.org; Wed, 26 Jul 2006 21:14:09 +0100
Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1G5plc-0000sT-6K for tls@ietf.org; Wed, 26 Jul 2006 21:14:04 +0100
Message-ID: <44C7BB74.5060902@blueyonder.co.uk>
Date: Wed, 26 Jul 2006 19:59:00 +0100
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
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> <44C7B157.70505@redhat.com>
In-Reply-To: <44C7B157.70505@redhat.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: david.nospam.hopwood@blueyonder.co.uk
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

Wan-Teh Chang wrote:
> 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.

As pointed out in the Security Considerations for the truncated_hmac
option in RFC 4366:

   Note that the output length of a MAC need not be as long as the
   length of a symmetric cipher key, since forging of MAC values cannot
   be done off-line: in TLS, a single failed MAC guess will cause the
   immediate termination of the TLS session.

As a result, HMAC is not a weak point in TLS for any ciphersuite.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls