Draft: draft-ietf-cose-msg

Commentary: Expand text for ECDSA and HMAC Add text for CMC - MAC
The ECDSA signature algorithm is parameterized with a hash function
(h.  In the event that the length of the hash function output is
greater than group of the key, the left most bytes of the hash output
are used.
The algorithms defined in this document can be found in table_ecdsa.
On of the issues that needs to be discussed is substitution attacks.
There are two different things that can potentially be substituted in
this algorithm.  Both of these attacks are current theoretical only.
The first substitution attack is changing the curve used to validate
the signature, the only requirement is that the order of the key
match the length of R and S.  It is theoretically possible to use a
different curve and get a different result.  We current do not have
any way to deal with this version of the attack except to restrict
the overall set of curves that can be used.
The second substitution attack is to change the hash function that is
used to verify the signature.  This attack can be mitigated by
including the signature algorithm identifier in the data to be
signed.
System which have poor random number generation can leak their keys
by signing two messages with the same value of 'k'.  RFC6979 provides
a method to deal with this problem by making 'k' be deterministic
based on the message content rather than randomly generated.
Applications which specify ECDSA should evaluate the ability to get
good random number generation and recommend this when it is not
possible.  Note: Use of this technique even when good random number
generation exists may still be a good idea.
There are two substitution that can theoretically be mounted against
the ECDSA signature algorithm.
Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one
could have a two messages with the same signature each computed
under a different curve.  The only requirement on the new curve is
that it's order be the same as the old one and it be acceptable to
the client.  An example would be to change from using the curve
P-256 to using Curve25519.  (Both are 256 bit curves.)  We current
do not have any way to deal with this version of the attack except
to restrict the overall set of curves that can be used.
Change the hash function used to validate the signature: If one
has either two different hash functions of the same length, or one
can truncate a hash function down, then one could potentially find
collisions between the hash functions rather than within a single
hash function.  (For example, truncating SHA-512 to 256 bits might
collide with a SHA-256 bit hash value.)  This attack can be
mitigated by including the signature algorithm identifier in the
data to be signed.
There is a theoretical hash substitution attack that can be mounted
against RSASSA-PSS.  However, the requirement that the same hash
function be used consistently for all operations is an effective
mitigation against it.  Unlike ECDSA, hash functions are not
truncated so that the full hash value is always signed.  The internal
padding structure of RSASSA-PSS means that one needs to have multiple
collisions between the two hash functions in order to be successful
in producing a forgery based on changing the hash function.  This is
highly unlikely.
The Hash-base Message Authentication Code algorithm (HMAC) RFC4231
was designed, in part, to deal with the birthday attacks on straight
hash functions.  The algorithm was also designed to all for new hash
algorithms to be directly plugged in without changes to the hash
function.  The HMAC design process has been vindicated as, while the
security of hash algorithms such as MD5 has decreased over time, the
security of HMAC combined with MD5 has not yet been shown to be
compromised RFC6151.
For use in constrained environments, we define a set of HMAC
algorithms that are truncated.  There are currently no known issues
when truncating, however the security strength of the message tag is
correspondingly reduced in strength.  When truncating, the left most
tag length bits are kept and transmitted.
TBD.
There are a set of different algorithms that we can specify here.
Which should it be?
AES-CMAC - RFC 4493 - has improved security over AES-CBC.  The
padding is different from CBC mode and requires one extra AES
block encryption step plus and xor operation.
The Hash-base Message Authentication Code algorithm (HMAC) RFC4231
was designed to deal with length extension attacks.  The algorithm
was also designed to allow for new hash algorithms to be directly
plugged in without changes to the hash function.  The HMAC design
process has been vindicated as, while the security of hash algorithms
such as MD5 has decreased over time, the security of HMAC combined
with MD5 has not yet been shown to be compromised RFC6151.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h) and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define a set of HMAC algorithms that are truncated.
There are currently no known issues when truncating, however the
security strength of the message tag is correspondingly reduced in
strength.  When truncating, the left most tag length bits are kept
and transmitted.
The algorithm defined in this document can be found in table-hmac.
For some key management methods, the length of the key is known or
determinable from the key management method.  For example, if RSA-
OAEP is used then the key will be output at the correct length.
However, if any of the key derivation methods are used, then the size
of the key to be obtained is an input parameter to the key derivation
step.  For all HMAC methods defined in this document, the key size
for a key derivation methods MUST be the same size as the hash
function used.  It is RECOMMENDED that the key size be the same size
as the hash function for all other key management methods.
HMAC has proved to be resistant even when used with weakening hash
algorithms.  The current best method appears to be a brute force
attack on the key.  This means that key size is going to be directly
related to the security of an HMAC operation.
AES-CBC-MAC is defined in MAC.
AES-CBC-MAC is parameterized by the key length, the authentication
tag length and the IV used.  For all of these algorithms, the IV is
fixed to all zeros.  We provide an array of algorithms for various
key lengths and tag lengths.  The algorithms defined in this document
are found in table-aes-mac.
A number of attacks exist against CBC-MAC that need to be considered.
If the same key is used for both encryption and authentication
operations, using CBC modes an attacker can produce messages with
a valid authentication code.
If the IV can be modified, then messages can be forged.  This is
addressed by fixing the IV to all zeros.