Russ Housley wrote:
Nikos:
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
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.
If this document were defining the ciphersuites, I might agree.
I agree that the Suite B document does not define (and therefore can
not fix) awkward design choices of existing TLS cipher suite specs.
Personally, I would never attribute a strength higher than 128-bits
symmetric to an AES_256_GCM cipher because of the limitation of the
MAC algorithm (AEAD) to 128 bits.
The longer hash does help in retaining entropy during the
MasterSecret derivation and the traffic keys derivation.
But I do not believe that SHA384 for the PRF is a sensible choice,
IMHO they should have used SHA512 instead -- which uses the *exact*
same algorithm, just a different internal start value and no output
truncation.
The trailing Hash algorithm (SHA256 / SHA384) following a symmetric crypto
algorithm (AES_128_GCM / AES_256_GCM) is also extremely confusing.
A trailing(!) hash algorithm name has originally been used to indicate
the hash for an HMAC-based integrity-protection.
The hash for the PRF ought to have been inserted directly after "TLS",
which would IMHO have been much less confusing.
And btw. I believe that rfc5288 is SERIOUSLY FLAWED in that it
says "MUST NOT be negotiated with other versions of TLS than v1.1",
because this is a very clear violation of rfc2119 section 6 and
entirely unnecessary.
The use of these cipher suites with TLSv1.0 or TLSv1.1 would be
simple and straight-forward (and that does include a SHA-256
and SHA-384 PRF). TLSv1.0 was explicitly designed to support
other hashes for the PRFs. While it may not be explicit in the
acutal TLSv1.1 spec, is was clearly addressed in the design
discussion, and it was implemented and shipped for Windows XP,
where you can plug-n-play a crypto provider that will allow
the use of Microsoft's SChannel (an implementation of
TLSv1.0 without support for TLS extensions) to use GOST TLS
cipher suites with all GOST algorithms, including a GOST-based
TLSv1.0 PRF.
In the same fashion, I am very strongly opposed that the Suite B
document contains a MUST USE for the signature algorithm TLS extension.
That MUST is entirely unnecessary, and a MAY perfectly sufficient.
A MUST precludes that the seriously fouled up extension in rfc5246
is updated/replaced with something much more reasonable in a successor
spec (in case that some folks would prefer a new TLS extension with
a sane definition -- the MUST NOT include signature algorithms in
ServerHello made the definition pretty much unfixable).
The availability of the TLSv1.2 PDUs for conveying the signature and
hash algorithm are perfectly sufficient for the interop, the TLS signature
extension could in theory help to disambiguate, but the algororithms
of client and server for the EC algorithms seem sufficiently interlocked
that I consider such ambiguity somewhat unlikely.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf