2.7.13 Security Area Directorate Open Meeting (saag)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20


Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Mailing Lists:

General Discussion: saag@mit.edu
To Subscribe: saag-request@mit.edu

Description of Working Group:

Goals and Milestones:

No Current Internet-Drafts

Request For Comments:

RFC3365 BCP Encryption and Security Requirements for IETF Standard Protocols

Current Meeting Report

		 Security Area Advisory Group (SAAG)
		      IETF64, Vancouver, Canada
	   Minutes compiled by Sam Hartman and Russ Housley

			Scribe: Jeff Hutzelman

Jabber Scribe: Eliot Lear

   Russ Housley presented the agenda:
      WG Reports
      BoF Reports
      Deploying a New Hash Function
      Security Area Response to Hash Function Breaks
      Open Microphone

   Working Group and BoF Reports (
   Each working group or BoF that had a meeting at IETF 63 gave a very
   brief summary of the session. Please see the minutes for each of
   these sessions. The highlights are not repeated here.
   Reports were given by:

     LTANS met but made no presentation at SAAG 
     EMU BOF

   Deploying a New Hash Function
     Eric Rescorla presented the paper he co-authored with Steve
     Bellovin  on deploying new hash functions in IETF protocols.  All
     the protocols analyzed required work in order to support new hash

   Security Area Response to Hash Function Breaks
     Russ said we should "walk, not run."  This is not a problem yet
     but as attacks are improved it will become a problem.  NIST held
     a hash workshop.  Conclusions from that workshop include a
     reminder that SHA-1 will reach end-of-life  for digital signatures by
     2010.  Also, we cannot expect any new standardized hash functions
     before then.  The security ADs have decided that we need to
     transition to sha-256 now.  There will probably be a later
     transition to something new after it is developed.  So, we need
     to become good at transitions as we have at least two.
     Protocols with active WGs will be analyzed within those WGs;
     others in SAAG.

     Directives to WGs/Chairs:
      Do analysis on every protocol in the WG by IETF 65
       Start standards work on transition to sha-256, but plan for
      future transitions.

     Several issues were discused.  In some cases it may be
   appropriate to transition away from a hash entirely to a MAC or
   other primitive.  There are concerns about the operational issues
   of transitions: protocol specification is only part of the
   problem.  Uri Blumenthal is concerned about the decision to choose
   sha-256.  He said that sha-256 is based on intuitive rather than
   scientific principles; we have already lost on that with sha-0 and
   sha-1.  Russ pointed out that there was a lot of discussion of that
   issue at the hash workshop and this is the best call we can make.
   Randomized hashing was discussed; in some cases this is a good
   idea.  However we don't have a recommended randomized hash
   construction.  We will handle protocols outside the security area
   as time goes on; we will lead by example by first solving problems
   within the area.  David McGrew is concerned that hmac-md5 may be
   the next target; hmac-sha-1 is still believed safe.

   Open Microphone

     Uri Blumenthal gave a presentation on a possible alternative to
     sha-1 during open mic.  His slides are included in the
     presentations.  Two major concerns were raised.  First it is not
     clear this work has had sufficient review.  Second, it would
     still leave us with a 160-bit hash, which would not meet our goal
     of getting to something longer by 2010.

     Nico Williams expressed disappointment that we were not
     discussing the KDF today.  Russ said that the KDF document needs
     work.  Russ said that the NIST document only covers one use of
     KDFs.  Sam indicated there was a lot of concern about NIST
     creating a situation where a lot of IETF protocols could not get
     FIPS 140-2 certification.  

     Sam pointed out that section 4.5 of RFC  3766 is an IETF BCP
     describing a key derivation function.  The NIST function seems a
     lot better; we probably want to fix 3766.


SAAG Agenda
Deploying a New Hash Function
IETF Security Area Response to the Hash Function “Breaks”
SHA-1 Hash Function Replacement