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 13:45:12
On 10/27/2011 07:37 PM, Russ Housley wrote:

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.

This is however, cannot be deducted from the document. The document
describes two combinations of suites one of 128-bit security level and
another of 192-bit. In the 128-bit security level a SHA-256 PRF is used
and in the 192-bit the SHA-384 PRF. To someone reading this document it
is apparent that the choice of the SHA-384 PRF is done to increase to a
192-bit security level. However, as you say this is not the case, and
this IMO deserves at least a sentence in the security considerations
section.

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

I believe I was clearly talking about the TLS PRF (The SHA384 in the
ciphersuite name refers to the PRF).

regards,
Nikos

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