The buzz in the Security Area at IETF 64 was all about hash functions. Hash functions-in particular MD5 and SHA-1-are a key part of nearly every IETF security protocol, so it was big news in 2004 when Wang et al. announced a practical attack on MD5 (http://eprint.iacr.org/2004/199.pdf) and even bigger news in February 2005 when it was announced that the security level of SHA-1 was substantially less than its design goal of 80 bits (http://theory.csail.mit.edu/~yiqun/shanote.pdf). Improved attacks have since lowered the security level of SHA-1 to 63 bits, just inside the range of what’s practical.
The three big questions on people’s minds were:
- Is my protocol still secure?
- What hash function should I be using now?
- How and when do I make the transition to a new protocol?
Although there were some differences of opinion, the consensus answers to these questions were more or less as follows:
- Most protocols are still safe, even if they use MD5. The one big exception here is protocols that use MD5 for digital signatures. This practice should be stopped as soon as possible. HMAC-MD5, which is in wide use for message integrity, is still believed safe but Cryptography Forum Research Group (CFRG) chair David McGrew expressed concern that it might be broken in the near future.
- Security Area Director Russ Housley recommends that new protocols not use SHA-1 and that the best current choice for a hash function is NIST’s SHA-256, however many attendees expressed hope that better candidates would emerge in the near future.
- Steve Bellovin, Russ Housley, and Eric Rescorla have studied the problem of hash function transitions in a number of existing IETF protocols (IPsec, S/MIME, SSL/TLS, DNSSEC, and OCSP) and in every case there are protocol problems preventing a clean transition. This means that transition steps have to be taken deliberately but need to start fairly soon.
Russ Housley has issued a call for the Security Area to review every major security protocol to determine the impact of hash function vulnerabilities and study transition strategies. Protocols that have working groups will be studied within those WGs. LTANS, PKIX, SMIME, Kerberos, and TLS have already started this process. Protocols that do not have WGs will be studied by the Security Area Advisory Group (SAAG). Volunteers are actively being solicited for this work.
Security Area Working Group meetings were fairly peaceful, with work quietly being accomplished. The Security Area held two BoFs: DKIM and EMU and one Security-related BoF (SIDR) was held in Routing.
Domain Keys Identified Mail (DKIM) is a protocol designed to allow e-mail servers to take responsibility for the messages they send. The intention is that this will be a useful tool for fighting spam and e-mail based fraud. This was the second DKIM BoF (the first was held in Paris) and the attendees were mostly in favor of the formation of a working group.
EAP Method Update (EMU) was an outgrowth of the SechMech BoF held at IETF63 in Paris. The intention here is to have a forum for the standardization of a small set of EAP methods that meet existing requirements from other SDOs. The mechanisms under consideration include additional shared secret mechanisms as well as public key based ones. There was general enthusiasm in the group for moving forward with this work.
Secure Inter-Domain Routing (SIDR) is an effort to design security mechanisms for Inter-Domain Routing (i.e. BGP) while avoiding some of the focus problems that the Routing Protocol Security (RPSEC) Working Group has had. There were presentations on the three major contending protocols: soBGP, sBGP, and psBGP. This work will also probably go forward, with the understanding that rather than picking one design the final design will pick the best technologies from each candidate.