ietf
[Top] [All Lists]

Re: Last Call: <draft-salter-rfc5430bis-01.txt> (Suite B Profile for Transport Layer Security (TLS)) to Informational RFC

2011-10-27 12:38:20
Nikos:

A comment on this draft is that it might be misleading on the 
security levels it claims. It mentions: "The Fact Sheet on Suite
B Cryptography requires key establishment and authentication 
algorithms based on Elliptic Curve Cryptography and encryption 
using AES [AES].  Suite B algorithms are defined to support two 
minimum levels of security: 128 and 192 bits."

However the (D)TLS Finished message is protected by a 96-bit
MAC, thus an attacker that can break a 96-bit MAC can manipulate
the TLS handshake in any way he desires (TLS version rollback,
removal of extensions and possibly more). IMO this disqualifies
the proposed ciphersuites from claiming more than 96-bits of
security.
It is important to distinguish between off-line and on-line
attacks. It is common (though perhaps not universal) to rate the
strength of cryptography in terms of resistance to off-line attack,
and that is what Suite B minimum levels of security express.

Having a second read on the document I don't think this is the case. The
document specifies
The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

The fact that the SHA-384 is used in the latter case in combination with
AES_256 it implies that SHA256 was replaced by SHA384 to increase the
security (the same way AES-128 was replaced by AES-256). However there
is no evidence that a 96-bit SHA384 based MAC is stronger than a 96-bit
SHA256 MAC.

Elsewhere in the Suite B profiles, SHA-384 is always paired with AES-256 and EC 
algorithms using the P-384 curve.  This selection was done for consistency.

Also, make sure you do not confuse the use of ECDSA with SHA-384 with HMAC with 
SHA-384.

Russ
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf