Subject: [TLS] Suite B compliance of TLS 1.2

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 25 Jul 2006 17:35:13 -0700

At the 2005 RSA Conference, the US National
Security Agency (NSA) announced Suite B Crytography
(http://www.nsa.gov/ia/industry/crypto_suite_b.cfm).
This suite of cryptographic algorithms includes AES,
ECDSA, ECDH, ECMQV, and SHA-256/SHA-384.

I'm interested in the Suite B compliance of TLS 1.2.
Simply put, it means the ability to do TLS 1.2 using
only Suite B algorithms.

The primary goal of TLS 1.2, to remove the protocol's
dependency on the MD5 and SHA-1 digest algorithms, is
in line with Suite B compliance.  I'd like to start
the discussion by proposing additional goals:
- merge in or reference RFC 4492
- add sha384 to the enumerated HashType
- define cipher suites whose MAC algorithm is Suite B
   compliant. Since Suite B doesn't include any MAC
   algorithms and the recent collision attack on SHA-1
   doesn't extend to HMAC-SHA-1, this goal may be
   controversial.

Wan-Teh Chang
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Jul 2006 21:32:28 -0700

> - merge in or reference RFC 4492

Well, I don't mind having an Informative reference
to RFC 4492, but merging it in really isn't appropriate,
since it's at Informational status and TLS 1.2 is of
course Standards Track.

> - add sha384 to the enumerated HashType

This was already decided on at IETF.

>    doesn't extend to HMAC-SHA-1, this goal may be

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.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Jul 2006 15:37:28 +0200 (MET DST)

> > - merge in or reference RFC 4492

AFAIK, the dependency on the combination of SHA-1 and MD5 is
hardwired into the protection of the SSL handshake,
and independent of the ciphersuite that is negotiated.

So in order to remove the dependency, one does not only need
new TLS ciphersuite, but also a significant change in the
handshake protocol (hashing of the handshake messages
and the creation/verification of the finished message).

Hashing the handshakes messages with both, old and new hash
algorithms and deciding later in the handshake which results
go into creation/verification of the finished message when
it has been determined/negotiated which algorithms to use
should be doable, and just moderately more expensive.

I'm slightly worried about the potential "market pressure"
which this might cause.  I certainly don't mind adoption/offering
of strong cryptographic protocols/technologies, but right
now I do NOT consider TLS fundamentally broken or weak,
and I would prefer if people focus on the acutal weaknesses
within the technology, rather than replacing the
(currently) strongest link in a weak chain with a much
stronger one.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Jul 2006 07:42:36 -0700

> and independent of the ciphersuite that is negotiated.

It is in 1.1, but not in 1.2.

> and the creation/verification of the finished message).

Yep. Those changes are already being made

> (currently) strongest link in a weak chain with a much

I'm sensitive to what you're saying and I have the same doubts.
On the other hand, I also worry about the attacks on MD5 and SHA-1
getting much worse and then having to explain why we didn't
do anything about it

-Ekr

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 26 Jul 2006 11:15:51 -0700

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Jul 2006 11:31:28 -0700

> Is GCM the new authenticated encryption mode?

We don't have one in process yet, but it's an obvious candidate.

-Ekr

---

From: Brian Minard <[email-masked]>
Date: Wed, 26 Jul 2006 14:46:48 -0400

On Tue, Jul 25, 2006 at 09:32:28PM -0700, Eric Rescorla wrote:

> > compliant. Since Suite B doesn't include any MAC algorithms
> > and the recent collision attack on SHA-1 doesn't extend to
> > HMAC-SHA-1, this goal may be controversial.
>
> 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 don't entirely understand these statements. Is there a reason
why new cipher suites supporting SHA-256, -384, or -512, couldn't
be defined using the existing HMAC? 

Why doesn't this solve the message integrity issue?

---

From: Brian Minard <[email-masked]>
Date: Wed, 26 Jul 2006 15:18:19 -0400

On Wed, Jul 26, 2006 at 11:49:56AM -0700, Eric Rescorla wrote:

> Brian Minard <[email-masked]> writes:
>
> > I don't entirely understand these statements. Is there a
> > reason why new cipher suites supporting SHA-256, -384, or
> > -512, couldn't be defined using the existing HMAC?
> >
> I was wondering the same thing... I.e., why Wan-Teh called the
> issue "controversial". Anyway, I was expecting that there would
> eventually be HMAC-XXX cipher suites.

Ok. It was my understanding that new cipher suites
supporting HMAC-XXX was within the scope of your
proposal in Montreal: How to negotiate a new
PRF--http://www3.ietf.org/proceedings/06jul/slides/tls-1.pdf,
page 7.

Was this proposal was accepted?

---

From: David Hopwood <[email-masked]>
Date: Wed, 26 Jul 2006 19:59:00 +0100

> 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 <[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Jul 2006 11:49:56 -0700

> Why doesn't this solve the message integrity issue?

I was wondering the same thing... I.e., why Wan-Teh called
the issue "controversial". Anyway, I was expecting that
there would eventually be HMAC-XXX cipher suites.

-Ekr