[ resurrecting ancient thread ] Andrei said on November 4, 2015.. > So perhaps the simplest fix is to update RFC 5929 to say that tls-unique > is deprecated and EKM should be used instead, with certain recommended > parameters. This does mean that any protocols that rely on tls-unique > will need to negotiate a new revision.
There are three distinct channel binding mechanisms in https://tools.ietf.org/html/rfc5929.. 3. The 'tls-unique' Channel Binding Type ...........................3 3.1. Description ................................................3 3.2. Registration ...............................................4 4. The 'tls-server-end-point' Channel Binding Type .................5 4.1. Description ................................................5 4.2. Registration ...............................................6 5. The 'tls-unique-for-telnet' Channel Binding Type ................6 5.1. Description ................................................7 5.2. Registration ...............................................7 ..is the proposal to update RFC 5929 to say that both tls-unique and tls-unique-for-telnet are deprecated and leave tls-server-end-point as is? Are there any known updates that ought to be applied to tls-server-end-point? Perhaps the allowed cipher suite list in S 6 ? Should an updated tls-unique-for-telnet based on RFC5705 EKM be defined in the proposed 5929bis draft? Or it could be left as a separate exercise for those who care about telnet I suppose. HTH, =JeffH _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
