Nikos: >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Suite B Profile for Transport Layer Security (TLS)' >> <draft-salter-rfc5430bis-01.txt> as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-10-31. Exceptionally, comments may be >> sent to i...@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. > > 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. However, there is no commonly agreed metric for strength against on-line attacks. In practice, resistance to on-line attack can be pragmatically stronger than resistance to off-line attack, while appearing to be mathematically weaker. In TLS, there is no off-line attack against the MAC in the finished message. To test a trial guess, the attacker must present it to the intended recipient on-line. The protocol only allows one chance to get the "finished" message right. If the message does not verify, there is a fatal error, the connection is terminated and all cryptographic keys for the connection are discarded. To be secure, the probability of success has to be low enough to be operationally impractical, as opposed to being low enough to be technologically infeasible. One could argue that a 32-bit or 64-bit MAC would be plenty generous for security; however, RFC 5246 already specifies that the MAC be no shorter than 96 bits. That is more than enough to be suitable with ANY metric for on-line cryptographic strength, not just 128 or 192 bits needed for Suite B. Thanks for the review, Margaret Salter Russ Housley _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
