Re: [Emu] RFC 7170 (TEAP) errata

[Jouni Malinen <[e-mail]>]

On Mon, Jul 22, 2019 at 01:50:26PM -0400, Joseph Salowey wrote:
> On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen <[e-mail]> 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