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(_at_)ietf(_dot_)org mailing lists by 2011-10-31. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf