Minutes taken by Paul Hoffman WGs LTANS was closed PKIX, EMU, OAUTH, NEA sent reports to the SAAG list KRB-WG IANA registration policy: want relaxed with good review Authorization in POSIX environments: lots of issues Camillia mode: not clear Making progress HOKEY, TLS, KITTEN, ABFAB, DANE will meet after SAAG DKIM will close after current RFC is published MSEC will close after current RFC is published IPSECME will close in Feb if there is no new work ISMS will likely close soon BOFs WOES did good work on the charter, will probably have it soon CICM sent report to the SAAG list Other WGs and BoFs related to security KARP had movemnt, and lots of interest in using IKEv2 for one of its protocols SIDR has 11 drafts in RFC Ed queue, plenty current work, including five since the recharter WEBSEC mainly look at HTTP headers for security functions, especially HSTS, working with W3C PLASMA did design work on the protocol spec; wants input on WS-trust; will have requirements draft soon MILE: follow-on from INCH, has a few drafts to work on, many people outside the IETF NIST SHA-3 Update Tim Polk, NIST Impact in the IETF Only covering what impacts implementations of IETF protocols History: well-known Has reasonable doubt of all older hashes SHA2 from the same family, has no plans to withdraw Threat to SHA2 is conjectural, not even theoretical Goals for SHA3 Plug-compatible with SHA-2 At least as strong And improve Tunable parameters brought confusion because it is not plug-comatible Tuning was to let NIST to give greater security assurance No tuning after competition Future: 2012-03: final conference 2012-summer: announcement of winner Will then wait for Sect. of Commerce to sign But the IETF can start once the winner is announced Impact on IETF protocols If the protocol has agility for hash algorithms, there should be no problem Really should be easy If not, you will have put agility into the protocol That will be harder If you have agility but haven't started doing SHA2, still have some work to do Buffer sizes, etc. Questions There will probably be long transition for PKIX NIST will probably just let SHA3 and SHA2 coexist without pushing SHA3 initially Still very happy with all five candidates on security Assumed that SHA3 would be faster on all platforms; didn't happen Will have some better speed on some platforms Won't get a jump of the same magnitude as AES Maybe deployment will be faster than with AES because we have much better crypto agility today Looking at Resource Constrained Crypto 8-bit devices, must also must be able to have an IP stack Lots of academic research done by the community is helping the discussion Issues in Identifier Comparison for Security Purposes Dave Thaler, IAB draft-iab-identifier-comparison-00 Lots of types of "identifiers" that might be compared Many entities can have the same identifier, such as caches There can be many protocols between parties Comparison can be different Three types of matches Absolute Definite (has an agreed-on comparison) Indefinite Sometimes cannot tell if something is of a particular type Looks at effects of false positive or negative Elevation of privilege worse than denial of service Things the IAB might recommend are listed in draft Discuss at i18n-discuss@iab.org Should think about whether tokens should be manufactured by the resource owner Sam Hartman thinks the recommendations are naive and all should be discarded Will try to clarify Why not use the term canonicalization? "Canonicalization" means something specific in Unicode context, wanted to avoid confusion with that specific meaning. Request to give this presentation in appsarea next ietf There are comparisons where there are no a canonical form, but they can be compared Adding KMP for IEEE 802.15 MAC security Each use of .15 (e.g. Zigbee, 6lowpan, zwave) must solve the key management one-by-one. 802.15.4 has very limited size Needs to be solved soon Documents are open, but IEEE mailing lists are not