1) TLS 1.2 status (RFC4346bis) Joe Salowey: Handling of version mismatch in pre-master secret to avoid side-channel attacks. Recommendation to keep the document as is. Eric Rescorla: Mechanism described in current draft and complicated and working is unclear. Original paper by Klima is hard to follow. He is planning to have discussions with some cryptographers and thinks better explanation is all that will be needed. 2) Extensions (RFC4366bis) Client cert url Joe Salowey: current proposal to make hash extension to be made mandatory. Other related topics - add hash agility and truncated HMAC Yoav Nir: Extension never been used in IKE or TLS and hence changes can be made. Eric: mentions that the issue was raised by NIST and Tim can comment on it. Tim not present. Pasi: clarifies NIST -- after you run the authentication protocol, parties would know who the peers are, and this isn't clear without the hash. Hence the need for hash inclusion. Joe: Hash agility can be added in a backward compatible way. Joe: show of hands for making hash mandatory shows a preference for making the hash mandatory w/o need of a new extension 4 for making existing hash mandatory 0 for new extension Take it too the list Pasi: Slide should not be about truncated hash but about max fragment length. (fix in slide) 3) cipher suite status Joe: Several drafts waiting on TLS 1.2 Badra: New Version submitted for EDCHE draft just before meeting Comment from jabber: Is there expired draft on ghost(?) cipher suites. Joe: Not sure what the status of the document is, it expired a while ago. 4) DTLS update (rfc4347bis) Abhijit Choudhury: Queries group about thoughts on aligning headers on word boundaries. Abhijit comments that unaligned headers increases die sizes on ASICs and this has been a historical problem inherited from TLS. Joe: so the problem is it requires more silicon to achieve the same speed. Joe: This change may be too big to include in DTLS 1.2 and preferable to discuss some more. Perhaps is possible to have a solution for TLS and DTLS. 5) TLS Key Generation draft-urien-tls-keygen-00 Joe: what is different about this than TLS extractor Pascal: difference with tls-extractor which uses a TLS PRF function is used and secondly the use case where server pushes the key which is not addressed by tls-extractor. Joe: why not use the same PRF ? Pascal: Is the same PRF function well suited for everything? Eric: What is the use case of this draft Pascal: for applications outside TLS or on top of TLS. A) Outside TLS for protocols like BGP ( peer to peer mode) or Push TV( server) Eric: applications for usage of keys outside of TLS is out of scope of this Working Group Pasi Eronen(AD): agrees. Joe: Agrees with Eric and Pasi's comments and recommends. If we are going pursue something like this, it should tie into the extractor draft as the extractor draft is going to be the default way of extracting keys from TLS. Bob Morgan: What type of implementation have you done Pascal: implemented what is in the draft, could be applied to many different things 6) Camellia cipher suites for TLS. draft-kato-tls-rfc4132bis-02 Joe: This may be better as an individual submission since it is only changing an encryption algorithm.