[Lake] Re: 🔔 Working Group Last Call (WGLC) of draft-ietf-lake-edhoc-grease-01

[Mališa Vučinić <[e-mail]>]

Thanks everyone for your feedback on this draft! I let Christian come back to the working group with responses and present them either during the interim in May or during IETF 126 in Vienna, before progressing the document.

Mališa 

> On Apr 26, 2026, at 21:32, Shujaatali Badami <[e-mail]> wrote:
> 
> read the full thread before writing this. Marco's editorial pass from March 31 looks solid to me and i have nothing to add to it. also went through Meiling's three questions from April 22 and Christian's responses. on Meiling's points i agree with where Issue #6 is heading,which is making section 2.1 explicit about either party use, and i agree with Christian that an algorithmic codepoint pattern like RFC 8701 doesnt really fit EDHOC, and that a zero length GREASE form would just create another ossification tier.
> 
> So i won't rehash any of that. below are seven things i didnt see anyone bring up yet, mostly on the constrained node side and the IANA forward-compatibility side.
> 
> 1. Section 6 is missing the RFC 8701 fallback prohibition
> 
> noticed RFC 8701 section 7 has this verbatim: "Implementations SHOULD NOT retry with GREASE disabled on connection failure", and reasoning is that such a fallback would let an attacker silently disable GREASE. current section 6 is just one sentence, and section 4 only really talks about operator reporting. nothing in the document tells an implementer not to retry without GREASE on failure. I'd suggest adding to section 6 something like:
> 
>   "Implementations SHOULD NOT retry an EDHOC session with GREASE disabled after a failure that may have been caused by GREASE."
> 
> this is just mirroring RFC 8701 and it lines up with how Christian himself used RFC 8701 as the authority in the April 22 thread.
> 
> 2. Section 2.1.1 should say something about randomness quality
> 
> Section 2.1.1 asks for random selection of probability, label, length and bytes, but it doesnt say anything about the quality of that randomness. Section 5 already mentions that the way GREASE is applied can fingerprint an implementation, so the concern is implicit, but its not pinned down. Class 1 devices per RFC 7228 often dont have a strong CSPRNG. a normative pointer to RFC 4086 or RFC 8937 for the trigger,label,length and value selection would close that.
> 
> 3. Forward compatibility with draft-spm-lake-pqsuites
> 
> draft-spm-lake-pqsuites is adding a "Supports DH/NIKE" column to the EDHOC Cipher Suites Registry with valid entries "Yes" and "No". current section 7.2 registers four cipher suite values with "the array N/A" and doesnt give a value for the new column. I dont know whether pqsuites will land before or after grease, but if pqsuites lands first this becomes a follow-up update on the GREASE rows, and if grease lands first the pqsuites authors will need to fill the column for the GREASE rows themselves. Easier to coordinate this once between the two drafts now. "No" with a footnote that GREASE entries are never selected seems like the natural answer, but i'll defer to the pqsuites authors and the chairs on the right wording.
> 
> 4. Section 7.2 registers cipher suite -41121 without an in-scope role
> 
> Within the in scope behavior described in section 3, which is placement at non-selected positions of SUITES_I, four registered cipher suite values are functionally interchangeable, you cant really tell them apart. Appendix A explicitly puts "placing a GREASE cipher suite in the selected position" out of scope, so the document never actually describes a scenario where the sign of a GREASE cipher suite codepoint matters. So -41121 ends up registered without a use case the document is willing to spell out. I dont see concerns regarding the other three, but for -41121 specifically i'd say either drop it and go down to three, or add a one line note in section 3 saying why a fourth, negative, value is reserved.
> 
> 5. Section 4 should name a concrete reporting venue
> 
> Christian himself flagged this gap on the IRTF ARMOR list back on November 3 2025. He said the current section 4 text "recommends that failures from it be detected and reported, but not how" (https://mailarchive.ietf.org/arch/msg/armor/sYsdIlUFXBYMw4zhOSDwRzDGssk/) Section 4 right now just points to RFC 9170 section 4.4 and stops there, no concrete venue. Since the Discussion Venues note at the top of the draft already names [e-mail] <mailto:[e-mail]> and the github tracker, one sentence in section 4 sending reporters there would make the feedback path actually operational and would close the gap Christian himself raised with the EDM and ARMOR folks.
> 
> 6. Test vectors
> 
> current IAB greasing draft recommends that GREASE enabled documents include test vectors. RFC 9529 (EDHOC Traces) doesnt have a single GREASE-bearing example. I'd suggest either a short appendix in this document running one non-critical GREASE EAD on message_2 using the algorithm in section 2.1.1, or a commitment in the shepherd writeup to fold one into the next traces revision. Christian mentioned wanting to do interop at IETF 122, and published vectors would actually let other implementers verify against the same baseline.
> 
> 7. IANA coordination with draft-ietf-lake-authz
> 
> draft-ietf-lake-authz registers EAD labels in the same EDHOC EAD registry that this draft is registering four GREASE labels into. both drafts are asking IANA for things in the same registry without cross referencing each other. I'd suggest the shepherd writeup just call this out explicitly, so authz EAD labels dont collide with the GREASE-reserved values, or with the future GREASE expansions section 2 already anticipates.
> 
> Overall i support advancement once items 1 and 4 are sorted, rest can be handled as the WG and chairs see fit. Thanks to Christian for a really clean document, and to the chairs for running the WGLC.
> 
> On Wed, Apr 22, 2026 at 11:13 AM Shujaatali Badami <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Mališa, all,
>> 
>> I can take the second WGLC review of grease-01. Comments to the list by Monday 27 April AoE.
>> 
>> Quick intro since this is my first post here. I'm an IEEE Senior Member based in Chicago, focused on post-quantum cryptography for constrained IoT and ICS (recent IEEE Access paper, DOI 10.1109/ACCESS.2026.3679234). Also on the PQ-EDHOC DT after the March CFI.
>> 
>> I'll skip editorial since Marco covered that, and focus on the constrained-node and IANA forward compatibility angles. More detail in the review itself.
>> 
>> Best,
>> 
>> On Wed, Apr 22, 2026 at 3:12 AM Mališa Vučinić <[e-mail] <mailto:[e-mail]>> wrote:
>>> Thanks, Marco, for providing your comments on this document!
>>> 
>>> @Christian: I let you come back to the working group once the editorial issues Marco raised are resolved.
>>> 
>>> @All: in order to proceed, we would need another set of eyes. Could I have another volunteer to review draft-ietf-lake-edhoc-grease-01 in the context of this WGLC?
>>> 
>>> Thanks,
>>> Mališa
>>> 
>>>> On Mar 31, 2026, at 13:39, Marco Tiloca <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I have re-read the document and I believe that it is basically ready.
>>>> 
>>>> Please find below some comments, largely editorial and for possible minor clarifications.
>>>> 
>>>> Best,
>>>> /Marco
>>>> 
>>>> 
>>>> 
>>>> [Title]
>>>> 
>>>> * Anticipating a request to expand "EDHOC", maybe the title can be:
>>>> 
>>>>   "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to the Extensibility of Ephemeral Diffie-Hellman Over COSE (EDHOC)"
>>>> 
>>>> 
>>>> [Abstract]
>>>> 
>>>> * Same as above about expanding acronyms:
>>>> 
>>>>   OLD
>>>>   > ... to the EDHOC ecosystem.
>>>> 
>>>>   NEW
>>>>   > ... to the ecosystem of Ephemeral Diffie-Hellman Over COSE (EDHOC).
>>>> 
>>>>   OLD
>>>>   > ... EAD labels ...
>>>> 
>>>>   NEW
>>>>   > ... External Authorization Data (EAD) labels ...
>>>> 
>>>> * It says:
>>>> 
>>>>   > It reserves a set of non-critical EAD labels and unusable ...
>>>> 
>>>>   Per Section 3.8 of RFC 9528, what can be "non-critical" is an EAD item (when its ead_label on the wire is positive), not the EAD label in itself. Proposed rephrasing:
>>>> 
>>>>   > It reserves a set of External Authorization Data (EAD) labels intended to be used in non-critical EAD items and a set of unusable ...
>>>> 
>>>> 
>>>> [Section 1]
>>>> 
>>>> * In the first paragraph, it's worth expanding "EDHOC" here too, as the first occurrence in the document body.
>>>> 
>>>> * Any reason to mention specifically version -02 of draft-edm-protocol-greasing ? Also, that Internet Draft has been formally replaced by draft-iab-protocol-greasing, which is likely the best reference to use here.
>>>> 
>>>>   (The same applies to the later Section 1.1)
>>>> 
>>>> * Third paragraph:
>>>> 
>>>>   * Repeating the reference to RFC 9528 should not be needed.
>>>> 
>>>>   * s/EADs (External Authorization Data items)/EAD (External Authorization Data) items
>>>> 
>>>>   * s/COSE headers/COSE header parameters
>>>> 
>>>> * It's good to add a new Section 1.2 "Terminology" including the BCP14 boilerplate (hence together with the references to RFC 2119 and RFC 8174).
>>>> 
>>>> 
>>>> [Section 1.1]
>>>> 
>>>> * It says:
>>>> 
>>>>   > If the selected method is unsupported by the peer, ...
>>>> 
>>>>   In practice, the peer in question that would consume a GREASE method specified in an EDHOC message is the Responder. Perhaps it's worth saying that?
>>>> 
>>>> * s/EAD options/EAD items
>>>> 
>>>> * s/COSE headers/COSE header parameters
>>>> 
>>>> * s/COSE header registry/"COSE Header Parameters" registry
>>>> 
>>>> 
>>>> [Section 2]
>>>> 
>>>> * It says:
>>>> 
>>>>   > This document registers the following EAD labels as GREASE EADs:
>>>> 
>>>>   Suggested:
>>>> 
>>>>   > This document registers the following GREASE EAD labels as usable by a GREASE EAD item:
>>>> 
>>>> * It says:
>>>> 
>>>>   > These EADs are available in all EDHOC messages. The EADs are used in their positive (non-critical) form.
>>>> 
>>>>   Suggested:
>>>> 
>>>>   > GREASE EAD items can be used in any EDHOC message and can only be non-critical (see Section 3.8 of [RFC9528]).
>>>> 
>>>> 
>>>> [Section 2.1]
>>>> 
>>>> * s/GREASE EADs/GREASE EAD items  (4 instances, including the title)
>>>> 
>>>> * s/GREASE EAD/GREASE EAD item
>>>> 
>>>> * Suggested rephrasing of the first paragraph, also building on the proposed new text for Section 2.0:
>>>> 
>>>>   > A sender of an EDHOC message MAY include an arbitrary number of GREASE EAD items, with any or no ead_value (that is, with or without a byte string of any usable length).
>>>> 
>>>> * ... from adding GREASE when its use would be ...
>>>> 
>>>>   Suggested rephrasing:
>>>> 
>>>>    > ... from including GREASE EAD items when this would be ...
>>>> 
>>>>    And later on
>>>> 
>>>>    > s/they might use it/senders might include those
>>>> 
>>>> 
>>>> [Section 2.2]
>>>> 
>>>> * s/party receiving a GREASE EAD/peer receiving a GREASE EAD item
>>>> 
>>>> * s/GREASE EADs/GREASE EAD items  (5 instances, including the title)
>>>> 
>>>> * s/an exchange/a session
>>>> 
>>>> * s/unprocessed EADs/unprocessed EAD items
>>>> 
>>>> * It says:
>>>> 
>>>>   > Implementations SHOULD NOT attempt to recognize GREASE EADs, and apply the default processing rules.
>>>> 
>>>>   Should the second part be extended as below?
>>>> 
>>>>   > Implementations SHOULD NOT attempt to recognize GREASE EADs, and SHOULD instead apply the default processing rules.
>>>> 
>>>> 
>>>> [Section 3]
>>>> 
>>>> * s/following cipher suites/following GREASE cipher suites
>>>> 
>>>> * s/these cipher suites/GREASE cipher suites
>>>> 
>>>> * It says:
>>>> 
>>>>   > Thus, these cipher suites never occur as the selected cipher suite. An initiator whose choice of a GREASE cipher suite is accepted needs to discontinue the protocol.
>>>> 
>>>>   The first sentence can be expanded as:
>>>> 
>>>>   > Thus, a GREASE cipher suite never occurs as the selected cipher suite, i.e., it is never specified as the last cipher suite within CRED_I in EDHOC message_1.
>>>> 
>>>>   (This would also be aligned with and clarify that "this document is concerned with test performed during successful operation", which comes only later in Appendix A)
>>>> 
>>>>   On the second sentence:
>>>> 
>>>>   * s/needs to discontinue the protocol/MUST discontinue the session
>>>> 
>>>>   * Can this actually happen? That would require that the same Initiator has indicated a GREASE cipher suite as the selected cipher suite in CRED_I, which is what the first sentence is ruling out.
>>>> 
>>>> 
>>>> [Section 4]
>>>> 
>>>> * s/GREASE related/GREASE-related  (2 instances, including the title)
>>>> 
>>>> * s/connections/sessions  (2 instances)
>>>> 
>>>> * s/connection/session
>>>> 
>>>> 
>>>> [Section 7.1]
>>>> 
>>>> * The first paragraph can be expanded with "... within the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group".
>>>> 
>>>> 
>>>> [Section 7.2]
>>>> 
>>>> * The first paragraph can be expanded with "... within the Ephemeral Diffie-Hellman Over COSE (EDHOC) registry group".
>>>> 
>>>> * There is no "Name" column in the "EDHOC Cipher Suites" registry. So maybe the "Description" can be updated as below:
>>>> 
>>>>   > "Unimplementable GREASE cipher suite to ensure extensibility"
>>>> 
>>>> 
>>>> [Appendix A]
>>>> 
>>>> * "critical (negative) use of the GREASE EAD labels"
>>>> 
>>>>   Suggested:
>>>> 
>>>>   > use of critical GREASE EAD items
>>>> 
>>>> 
>>>> [Nits]
>>>> 
>>>> * Section 1
>>>> --- s/addtional/additional
>>>> 
>>>> * Section 1.1
>>>> --- s/for GREASE/for GREASE in
>>>> --- s/e.g./e.g.,
>>>> 
>>>> * Section 3
>>>> --- s/initiator/Initiator  (2 instances)
>>>> --- s/responder/Responder
>>>> 
>>>> * Section 6
>>>> --- s/the GREASE option/GREASE
>>>> 
>>>> * Appendix A
>>>> --- s/e.g./e.g.,
>>>> --- s/particulary/particularly
>>>> 
>>>> From: Mališa Vučinić <[e-mail] <mailto:[e-mail]>>
>>>> Sent: Monday, March 30, 2026 2:18 PM
>>>> To: lake <[e-mail] <mailto:[e-mail]>>
>>>> Subject: [Lake] 🔔 Working Group Last Call (WGLC) of draft-ietf-lake-edhoc-grease-01
>>>>  
>>>> Hi all,
>>>> 
>>>> As discussed in Shenzhen during the IETF 125 meeting, we are now ready to launch the Working Group Last Call (WGLC) of draft-ietf-lake-edhoc-grease-01.
>>>> 
>>>> You can find the datatracker entry with the  status of the document at: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-grease/
>>>> 
>>>> The version of the document that is being WGLC-ed is at: https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-grease/01/
>>>> 
>>>> Please provide your comments on the readiness of this document to proceed by Monday, 13 April 2026, AoE.
>>>> 
>>>> Mališa, for the chairs
>>> 
>>> -- 
>>> Lake mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
> 
> --
> Shujaatali (Ali) Badami
> IEEE Senior, ComSoc. & ACM Member
> (MSc. DS, MBA)
> 
> E: [e-mail] <mailto:[e-mail]>
> W: shujaatalibadami.com <http://shujaatalibadami.com/>
> L: LinkedIn <https://www.linkedin.com/in/s-ali-badami/>
> The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.