> -----Original Message----- > From: Jari Arkko <jari.ar...@piuha.net> > Sent: Wednesday, November 14, 2018 9:47 AM > To: Jim Schaad <i...@augustcellars.com> > Cc: emu@ietf.org; draft-ietf-emu-rfc5448...@ietf.org > Subject: Re: [Emu] WGLC for draft-ietf-emu-rfc5448bis > > 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, All of what you said makes complete sense to me. As I said I was asking for curiosity value and not because I thought this should hold up the document from progressing. The one change I think you might consider doing is to put a "future version note" into the document with the suggestion that this be considered. If the reason was just oversight I would hate for the same oversight to be made later and a new EAP method be registered. Jim > > Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
