On Mon, Jul 22, 2019 at 01:50:26PM -0400, Joseph Salowey wrote: > On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen <jkmali...@gmail.com> wrote: > > (1) Crypto-Binding TLV format for the cases where the negotiated TLS > > cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and > > I'd hope all deployments of TEAP would be recent enough to avoid use of > > SHA-1..): > > https://www.rfc-editor.org/errata/eid5768
> > [Joe] I'd like to hear if anyone has an implementation, and how they > implemented on a cipher suite that is not SHA-1. My feeling is that it > would be better to make the TLV length variable with the hash length. > However, I do not see why truncating would work as well. For now, I ended up implementing this with truncation to 20 octets since it was a bit simpler to do. I have an implementation with support for SHA-1, SHA-256, and SHA-384; and not allowing MD5 at all to avoid questions about shorter than 20 octets and use of obsolete algorithms. That said, I think it would be better to make the Compound MAC fields to be of variable length (i.e., be based on the output length of the negotiated MAC algorithm) so that the full MAC value can be exchanged. This would mean the Crypto-Binding TLV length would need to be marked variable. I'm ready to change my implementation to do this as soon as there is some clear indication on that being the direction TEAP should go to. This is a straightforward change in the implementation, but I don't want to be moving back and forth on this before seeing some signs of consensus on the TEAP specification side. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
