Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS in [RFC8701], to Ephemeral Diffie-Hellman Over COSE (EDHOC, [RFC9528]) ecosystem.¶

The introduction of [RFC8701] and Section 3.3 of [RFC9170] provide comprehensive motivation for adding such extensions; [I-D.iab-protocol-greasing] provides additional background that influenced this document.¶

The extension points of the EDHOC protocol are cipher suites, methods, EAD (External Authorization Data) items and COSE header parameters. This document utilizes the cipher suite and EAD extension points.¶

Unlike in TLS GREASE [RFC8701], EDHOC is operating on tight bandwidth and message size budget, with some messages just barely fitting within relevant networks' fragmentation limits. Thus, more than with TLS GREASE, it is up to implementations to decide whether in their particular use case they can afford to send additional data.¶

2. The GREASE EAD labels

This document registers the following EAD labels for use with GREASE EAD items:¶

160, 41120, 43690, 44975¶

These EAD labels can be used in any EDHOC message for non-critical EAD items (see Section 3.8 of [RFC9528]).¶

The numbers cover the different lengths of encoding available in CBOR for the registry's range (except the 23 precious small values). It is expected that future documents register additional values with the same semantics.¶

3. GREASE cipher suites

This document registers the following GREASE cipher suites:¶

160, 41120, -41121, 43690¶

The numbers cover the different lengths of encoding available in CBOR for the registry's range (except the 46 precious small values), and both available signs. It is expected that future documents register additional values with the same semantics.¶

An Initiator may insert a GREASE cipher suite at any position in its sequence of preferred cipher suites.¶

A Responder MUST NOT support any of these GREASE cipher suites, and MUST treat them like any other cipher suite it does not support.¶

Thus, a GREASE cipher suite never occurs as the selected cipher suite, i.e., it is never specified as the last cipher suite in EDHOC message_1. An Initiator whose offer of a GREASE cipher suite is accepted through cipher suite negotiation (Section 6.3 of [RFC9528]) needs to discontinue the protocol.¶

4. Processing of GREASE-related failures

It is RECOMMENDED that any counters or statistics about successful and failed sessions distinguish between sessions in which GREASE was applied and those in which it was not applied. Any operator feedback channel, be it immediately to the user or through network monitoring, SHOULD warn the operator if there are errors that were determined to originate from the use of GREASE or that are significantly likely to originate from there. This provides a feedback path as described in Section 4.4 of [RFC9170].¶

On constrained devices, one suitable operator feedback channel is CORECONF [I-D.ietf-core-comi]; no general YANG model is available for that purpose.¶

Whether logging of GREASE-related failed session details is appropriate depends on the privacy policies of the application.¶

5. Privacy considerations

The way in which GREASE is applied can contribute to identifying which implementation of EDHOC is being used. Implementers of EDHOC are encouraged to use the algorithm described in Section 2.1.1, both to reduce the likelihood of their implementation to be identified through the use of GREASE and to increase the anonymity set of other users of the same algorithm.¶

6. Security Considerations

The use of GREASE has no impact on security in a correct EDHOC implementation.¶

As the application of GREASE contributes to an ecosystem that can have security updates deployed in the future, implementers of EDHOC are strongly encouraged to apply GREASE regularly whenever their operational constraints permit it.¶

7. IANA considerations

8. References

Appendix A. Using extension points beyond successful EDHOC runs

Some ways of using the extension points, in particular the use of critical GREASE EAD items and placing a GREASE cipher suite in the selected position do not result in the successful continuation of the EDHOC session.¶

They can be useful during testing (e.g., to verify that a peer does indeed implement the correct behavior of not silently tolerating critical EAD items it can not process), particularly when they allow a testing system to provoke an error response from the implementation under test. However, this document is concerned with test performed during successful operation, therefore that application is out of scope.¶

Appendix B. Change log

Since draft-ietf-lake-edhoc-grease-01: Address a WGLC comment that was missed.¶

• Using EADs by sender: Point out that both parties are senders and can grease any message.¶

Since draft-ietf-lake-edhoc-grease-01: Address WGLC comments.¶

• seccons: Strongly encourage use of GREASE¶

• Explicit SHOULD on applying default processing rules (not just by exclusion of SHOULD NOT attempt)¶

• Point to EDHOC CS-RNG for fingerprint resistance¶

• Point to CORECONF as example of how to report¶

• Add remark on why numeric values were chosen¶

• Elaboration on cipher suite selection¶

• Added BCP14 boilerplate Terminology section¶

• Updated reference from edm-protocol-greasing-02 to iab-protocol-greasing (currently at -01)¶

• Editorial fixes; highlights:¶

  • Consistency around "EAD items" and "EAD labels"¶

  • EAD items can be critical/non-critical, not labels¶

Since draft-ietf-lake-edhoc-grease-00: Resolve all open issues.¶

• Question on "is this better than padding" removed. (There are currently implementations of EDHOC that can't use all EAD values but can do padding).¶

• Question of COSE header extension deferred to COSE maintenance.¶

• Use of GREASE values in critical form is out of scope, but appendix illustrates that it can make sense to do, and emphasizes that indeed those options do cause errors when used with negative sign.¶

Since draft-amsuess-lake-edhoc-grease-01:¶

• Document was adopted in LAKE.¶

• Instead of discouraging GREASE around fragmentation limits wholesale, suggest reduced frequency.¶

• Editorial fix to fingerprinting section.¶

Since draft-amsuess-lake-edhoc-grease-00:¶

• Expanded introduction section to just point to the abstract any more.¶

Since draft-amsuess-core-edhoc-grease-01:¶

• Update references to RFC9528 🎉¶

• Change target WG to LAKE, renaming to draft-amsuess-lake-edhoc-grease¶

• Process RFC9170¶

  • Add a section on failure processing¶

  • Reference where appropriate¶

• Process draft-edm-protocol-greasing-02¶

  • Variability outside of extension points¶

  • Be firmer against recognizing GREASE values¶

  • Point out that future options may be registered (instead of the suggested algorithmic registrations)¶

Since -00:¶

• Fixed a mix-up between positivity and criticality of options.¶

• Adjusted numbers accordingly to once more fit in the 0xa. pattern (actually they're using 0x.a, but that doesn't work the same way with CBOR).¶

• Text improvements around recipient side processing.¶

Acknowledgements

Marco Tiloca pointed out a critical error in the numeric constructions, and provided many general improvements. Göran Selander provided input to reduce mistakable text. Meiling Chen and Shujaatali Badami found places where the text did not provide the right guidance to readers.¶

Author's Address