Hi Murray, IESG, Sorry for the somewhat long email but I thought it is worth elaborating on the history of this document a little. I guess many of us struggled with the question if LWIG is the right venue before this document was adopted. Suresh (AD at the time of adoption), Ben Kaduk, and I (co-chair) did note that this draft is crypto-dense. Ben in 2019 asked:
Hi all, I happened to see the IoTdir review of draft-ietf-lwig-curve-representations go by, and was kind of struck by how math/crypto-dense it was (and how long it was). It's really the sort of thing I expect to see come out of CFRG, and doesn't strike me as really LWIG's core competency. Could you say a bit more about why it's being pursued in LWIG? Thanks, Ben and Suresh responded: Yes. It has been very concerning to me and and I did raise my concern several times with the IESG including the last time at the IESG wrap up meeting for Prague on March 29. I was also concerned about the crypto heavy nature and proceeded based on the Stanislav Smyshlyaev review from the Crypto Review panel. I had also specifically asked for a SecDir review before I send this off to IETF LC but the Sec Dir review due on 10/04 has not arrived yet. I will let Mohit and Zhen make the call, but if you think the cfrg would be a good venue for this I would personally be happy to approve the move. Thanks Suresh I think some of our concerns were assuaged because this draft was sent to the IETF Crypto Review Panel (https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel) through Alexey Melnikov. Stanislav Smyshlyaev reviewed the document and the formulae. I believe comments from the Crypto Review Panel were addressed by Rene. Ben later responded: Hi Mohit, I didn't know that Stanislav had done a crypto review (or rather, I forgot, since I think I am on that mailing list as a courtesy); he does good work, and that alleviates most of my concerns. My gut feeling remains that CFRG is "more appropriate" in some abstract sense, but it's not clear that the benefit of moving the document is worth any gains that might be had. Hopefully one of us can remember to forward the IETF LC note to the CFRG when that happens, which should be enough awareness there. Thanks for the extra background, Ben LWIG has done lots of security related RFCs and drafts: RFC 7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation: https://datatracker.ietf.org/doc/rfc7815/ RFC 8387: Practical Considerations and Implementation Experiences in Securing Smart Object Networks: https://datatracker.ietf.org/doc/rfc8387/ draft-ietf-lwig-minimal-esp: Minimal ESP: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ When Rene's draft was adopted, there were no IANA registrations (https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-00#section-5). As it happens sometimes, the scope of the work expanded after working group adoption and perhaps everyone involved could have been more diligent. I understand the IESG concerns about LWIG charter not covering this work item precisely. But as an individual contributor: I think we are at a point of diminishing returns and pursuing this document elsewhere is perhaps not the best choice. I like Carsten's suggestion of reverting this document to informational and allowing some values to be registered even if they require standards action. Carsten explains the logic rather nicely here: https://mailarchive.ietf.org/arch/msg/cose/g8UaczrsG6zHqR6qDIxRt-JJMtM/ Obviously, you, the IESG members have way more experience than me and I'll follow your recommendations here (both as co-chair and document shepherd). --Mohit On 2/18/21 4:29 AM, Murray S. Kucherawy wrote: On Wed, Feb 17, 2021 at 10:57 AM Rene Struik <[email protected]<mailto:[email protected]>> wrote: I am sure you have much more process experience than I do. However, I have trouble understanding how having a IANA section makes this suddenly a process violation. Do I understand correctly that, in your mind, this process issue would be moot if I would simply partition the doc into two parts A and B, where C:=A+B is the current document and where A=C\B and B:={Section 12.2, Section 12.3}? [...] I simply would like to understand, since I do not right now. Hopefully this helps rather than muddies things further, and Magnus (and Erik, and Ben, etc.) can correct me if I'm wrong: The first issue: The Last Call announcement for this document indicated that the working group wants it to have Informational status when published. After that Last Call was completed, our procedures assert that the document, with any Last Call feedback worked into it, has IETF consensus to be published with that specific status. Changing the status being sought to Standards Track without also running a new Last Call saying so violates our procedures; the document can't go forward unless that status change is reverted, or a second Last Call is done indicating the new intended status. This point has nothing at all to do with the content of the document, but rather the path it has followed through the process so far. The second issue: The LWIG working group does not appear (on a cursory read) to be chartered to produce a document that does this sort of work with cryptographic algorithms. Since a working group's charter is in effect a contract between the working group and the IESG to describe exactly the work it will produce, the delta between what this document is doing and what LWIG's charter says is large enough that this is something worthy of discussion and resolution before the document should advance. If the charter is wrong, let's renegotiate it; if this work needs to be done in a different venue, let's make that arrangement; etc. I believe Magnus is right to put the brakes on until these issues are sorted out. -MSK _______________________________________________ Lwip mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lwip
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
