Subject: [Ietf-krb-wg] summary re SHA-1 obsolescence

From: Tom Yu <[email-masked]>
Date: Mon, 20 Jul 2009 20:54:52 -0400

Based on recent messages to this WG mailing list, as well as input
from MIT Kerberos Consortium sponsors, I wish to note the following
observations:

* HMAC-SHA-1 is probably safe for now

* digital signature and related SHA-1 uses that require collision
  resistance should migrate toward stronger hashes

* migrating away from SHA-1 for the AES cryptosystems for PR reasons
  is not worth the interoperability risks (my corollary -- we should
  work on preparing a statement explaining in fairly accessible
  language why the use of SHA-1 in Kerberos AES cryptosystems is not
  vulnerable)

* PR concerns related to laypeople's misunderstandings of NIST mandate
  to cease using SHA-1 for digital signature or other collision
  resistance uses are not sufficient to motivate a migration away from
  HMAC-SHA-1 in the AES cryptosystems

* the use of ciphertext stealing (CTS) in existing AES cryptosystems
  presents real problems for implementations

* there is limited utility to migrating to SHA-2 when it's likely that
  we will very soon need a migration to SHA-3

* authenticated encryption with additional data (AEAD) cipher modes
  may be more interesting that dropping in another hash (SHA-2 or
  SHA-3) into existing AES cryptosystems

* HMAC truncation may be a problem; it certainly appears to not be
  fully justified in RFC 3962

I would also like to suggest the following courses of action for this
WG:

* do nothing (for now) to specify an AES cryptosystem that uses SHA-2
  or SHA-3

* prepare a statement (informational RFC?) about why HMAC-SHA1 as used
  in the AES cryptosystems is safe and not subject to the NIST mandate
  to phase out SHA-1

* arrive at some agreement about what shape an AES-SHA-2 or AES-SHA-3
  cryptosystem would look like (CTS or not; HMAC truncation or not)

* be prepared for rapid movement if/when the cryptographic community
  finds some serious flaws with SHA-1 preimage resistance or HMAC-SHA1

* investigate how we would best specify AEAD encryption modes, or at
  the very least how we should adopt optimized authenticated
  encryption modes such as AES-CCM or AES-GCM

Please respond if you disagree with the above, and please feel free to
suggest additional points I may have missed.  Thanks.

-- 
Tom Yu
Development Team Leader
MIT Kerberos Consortium
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Tue, 21 Jul 2009 10:38:09 +0200

>  encryption modes such as AES-CCM or AES-GCM

I did some experimental work on AES-CCM last year, see:

http://src.mit.edu/fisheye/browse/krb5/branches/aes-ccm

Have not got around to writing it up, but some notes are at:

http://src.mit.edu/fisheye/browse/~raw,r=21633/krb5/branches/aes-ccm/ 
src/lib/crypto/dk/dk_ccm.c

cheers,

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Sun, 26 Jul 2009 07:01:29 -0400

Tom, I agree with your summary, except that I don't see value in
investigating aes-sha2 or aes-sha3.

I would instead prefer to work on aes-{ccm|gcm} either as an AEAD mode
or as a traditional RFC 3961 mode.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 26 Jul 2009 17:16:33 -0500

> or as a traditional RFC 3961 mode.

I agree.

Nico