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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf