Thanks for your review, Jim. > Any issues that I have here might have already been raised and discussed. If > so just not that and ignore. > > Section 3.4 - I am curious why you did not make the hash function a property > of the HKDF function rather than making it a hard coded value. I would kind > of expect that section 3.4 (top) and 3.4.1 would be part of the KDF function > and not stand alone values. I am not sure if I think that the MAC function > should also be defined by this as well. Doing so would allow for an easier > jump to SHA3 at a later date if needed. > > Other than that question the document is clear and the EMU parts seem to be > correct. I cannot comment on any of the 3GPP parts.
Good questions. I’m not sure I can entirely answer what the thinking was without going through past correspondence; I can’t recall. I’m not sure we were clever enough to do what you suggested back then, this could be just a missed opportunity. But I could be missing some reason why we didn’t do it. Thinking about it now, tying AT_MAC, AT_CHECKCODE, PRF, *and* KDF all to AT_KDF value would make sense. However, that would seem like a change to a design that was in RFC 5448, and if we change that there will be two questions: (a) can we do it and (b) should we do it? It seems like that answer to the first question is that we can, because even if (e.g.) AT_MAC appears before KDF negotiation is completed, if the peer does not want to do the requested KDF/hash functions, it will in any case propose new KDF before running the actual crypto. The answer to the second question may be trickier. If I’m right above, we could make a change without requiring any new code lines in existing implementations, but it would still be a change. And if we made that kind of change, there’d probably be a wish from 3GPP to review that change as well. And possibly a request to discuss the change, or do further development. This is what makes me hesitate a bit. But I’ll also observe that a future document that introduces SHA-16384 could certainly define all this anyway; peers that can not do the KDF/hash that is proposed would suggested the older algorithms instead, and crypto would only run once both parties agree on what is negotiated in AT_KDF. I’ll think about this some more, but this seems at the moment preferable to me. Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
