Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility
draft-ietf-lake-edhoc-grease-03

LAKE                                                           C. Amsüss
Internet-Draft                                               6 July 2026
Intended status: Informational                                          
Expires: 7 January 2027

 Applying Generate Random Extensions And Sustain Extensibility (GREASE)
                         to EDHOC Extensibility
                    draft-ietf-lake-edhoc-grease-03

Abstract

   This document applies the extensibility mechanism GREASE (Generate
   Random Extensions And Sustain Extensibility), which was pioneered for
   TLS, to the ecosystem of Ephemeral Diffie-Hellman Over COSE (EDHOC).
   It reserves a set of External Authorization Data (EAD) labels and
   unusable cipher suites that may be included in messages to ensure
   peers correctly handle unknown values.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Lightweight
   Authenticated Key Exchange Working Group mailing list
   (lake@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/lake/.

   Source for this draft and an issue tracker can be found at
   https://github.com/lake-wg/grease.

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.

Amsüss                   Expires 7 January 2027                 [Page 1]
Internet-Draft   Applying Generate Random Extensions And       July 2026

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Variability in other extension points . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The GREASE EAD labels . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Use of GREASE EAD items by message senders  . . . . . . .   4
       2.1.1.  Pattern for limited fingerprinting  . . . . . . . . .   4
     2.2.  Use of GREASE EAD items by message recipients . . . . . .   5
   3.  GREASE cipher suites  . . . . . . . . . . . . . . . . . . . .   5
   4.  Processing of GREASE-related failures . . . . . . . . . . . .   6
   5.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  EDHOC EAD labels  . . . . . . . . . . . . . . . . . . . .   6
     7.2.  EDHOC cipher suites . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Using extension points beyond successful EDHOC
           runs  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Appendix B.  Change log . . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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.

Amsüss                   Expires 7 January 2027                 [Page 2]
Internet-Draft   Applying Generate Random Extensions And       July 2026

   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.

1.1.  Variability in other extension points

   If the selected method is unsupported by the Responder, EDHOC does
   not conclude successfully.  While values could be reserved for these
   for use as GREASE, these failed attempts would not be verified
   between the EDHOC participants without maintaining state between
   attempted EDHOC sessions.  Such an addition is considered impractical
   for constrained devices, and thus out of scope for this document.

   Recommendations for GREASE in Section 4 of
   [I-D.iab-protocol-greasing] also include varying other aspects of the
   protocol, such as varying sequences of elements.  EDHOC has little
   known variability, and intentionally limits choice at times (for
   example, Section 3.3.2 of [RFC9528] allows only the numeric
   identifier form where that is possible).  Where variation is allowed,
   e.g., in padding or in the ordering of EAD items, applications are
   encouraged to exercise it.

   The extension point of COSE header parameters (identifying other
   ID_CRED_x types) is beyond the scope of this document, and might be
   addressed orthogonally in the "COSE Header Parameters" registry.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Amsüss                   Expires 7 January 2027                 [Page 3]
Internet-Draft   Applying Generate Random Extensions And       July 2026

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.

2.1.  Use of GREASE EAD items by message senders

   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).  Both parties (the Initiator and
   the Responder) can send GREASE EAD items in any EDHOC message,
   without any need for coordination.

   Senders SHOULD consider the properties of the network their messages
   are sent over, and refrain from adding GREASE when its use would be
   detrimental to the network (for example, they might use it less
   frequently when the added size causes fragmentation of the message).

   On networks where the data added by the grease EAD items does not
   significantly impact the network, senders SHOULD irregularly send
   arbitrary (possibly random) GREASE EAD items with their messages to
   ensure that errors resulting from the use of GREASE are detected.

   The GREASE EAD items MAY be used as an alternative form of padding.

2.1.1.  Pattern for limited fingerprinting

   A method of applying GREASE is suggested as follows:

   *  For every message, use GREASE with a random probability of 1 in
      64.

   *  Pick a random GREASE label out of the uniform distribution of
      available options.

   *  Pick a random length from the uniformly distributed interval 9 to
      40 (inclusive).

Amsüss                   Expires 7 January 2027                 [Page 4]
Internet-Draft   Applying Generate Random Extensions And       July 2026

   *  Add the selected GREASE label with a value of the selected length,
      filled with random bytes.

   Running EDHOC already requires the presence of a cryptographically
   secure random number generator.  Implementers can use that same
   source here to avoid any privacy implications from insufficiently
   initialized faster sources of randomness.

2.2.  Use of GREASE EAD items by message recipients

   A party receiving a GREASE EAD item MUST NOT alter its behavior in
   any way that would allow random GREASE EAD items to alter the
   security context that gets established.

   It MAY alter its behavior in other ways; in particular, it SHOULD
   randomly insert GREASE EAD items in later messages of a session in
   which unprocessed EAD items (including GREASE EAD items) were
   present.

   Implementations SHOULD NOT attempt to recognize GREASE EAD items, and
   SHOULD apply the default processing rules.

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.

Amsüss                   Expires 7 January 2027                 [Page 5]
Internet-Draft   Applying Generate Random Extensions And       July 2026

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

7.1.  EDHOC EAD labels

   IANA is requested to register four new entries into the EDHOC
   External Authorization Data Registry established in [RFC9528]:

   160, 41120, 43690, 44975

   All share the name "GREASE", the description "Arbitrary data to
   ensure extensibility", and this document as a reference.

Amsüss                   Expires 7 January 2027                 [Page 6]
Internet-Draft   Applying Generate Random Extensions And       July 2026

7.2.  EDHOC cipher suites

   IANA is requested to register four new values into the EDHOC Cipher
   Suites Registry established in [RFC9528]:

   160, 41120, -41121, 43690

   All share the array N/A, the description "Unimplementable GREASE
   cipher suite to ensure extensibility", and this document as a
   reference.

8.  References

8.1.  Normative References

   [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
              "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
              DOI 10.17487/RFC9528, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9528>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [RFC8701]  Benjamin, D., "Applying Generate Random Extensions And
              Sustain Extensibility (GREASE) to TLS Extensibility",
              RFC 8701, DOI 10.17487/RFC8701, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8701>.

   [RFC9170]  Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
              Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
              December 2021, <https://www.rfc-editor.org/rfc/rfc9170>.

   [I-D.iab-protocol-greasing]
              Pardue, L., Pauly, T., and D. Thaler, "Considerations For
              Maintaining Protocols Using Grease and Variability", Work
              in Progress, Internet-Draft, draft-iab-protocol-greasing-
              01, 5 July 2026, <https://datatracker.ietf.org/doc/html/
              draft-iab-protocol-greasing-01>.

Amsüss                   Expires 7 January 2027                 [Page 7]
Internet-Draft   Applying Generate Random Extensions And       July 2026

   [I-D.ietf-core-comi]
              Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
              and C. Bormann, "CoAP Management Interface (CORECONF)",
              Work in Progress, Internet-Draft, draft-ietf-core-comi-21,
              2 March 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-core-comi-21>.

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

Amsüss                   Expires 7 January 2027                 [Page 8]
Internet-Draft   Applying Generate Random Extensions And       July 2026

   *  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

Amsüss                   Expires 7 January 2027                 [Page 9]
Internet-Draft   Applying Generate Random Extensions And       July 2026

   *  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

   Christian Amsüss
   Austria
   Email: christian@amsuess.com

Amsüss                   Expires 7 January 2027                [Page 10]