Re: [auth48] AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for your review

[John Mattsson <[e-mail]>]

Dear RFC Editor,

See answers to the questions inline.

Cheers,
John Prueß Mattsson

From: [e-mail] <[e-mail]>
Date: Friday, 1 March 2024 at 03:03
To: Göran Selander <[e-mail]>, John Mattsson <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9529 <draft-ietf-lake-traces-09> for your review
Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search. -->

John: test vector, lightweight, authenticated key exchange, LAKE, AKE

2) <!--[rfced] FYI, to match usage in [RFC9528], we have updated
"static-ephemeral" to "ephemeral-static" for consistency. Please let us
know if this is not accurate.

Original:
   The endpoints use NIST P-256 [SP-800-186] for
   both ephemeral-ephemeral and static-ephemeral Diffie-Hellman key
   exchange.

Current:
   The endpoints use NIST P-256 [SP-800-186] for
   both ephemeral-ephemeral and ephemeral-static Diffie-Hellman key
   exchange.
-->

John: That is great.

3) <!--[rfced] The following lines are not complete sentences. Please
review and let us know if/how they should be updated.

Original (Section 3.4):
   The Responder's static Diffie-Hellman P-256 key pair:

Original (Section 3.5):
   The Initiator's static Diffie-Hellman P-256 key pair:
-->

OLD: The Responder's static Diffie-Hellman P-256 key pair:
NEW: The Responder's static Diffie-Hellman P-256 key pair consist of a private key and a public key.

OLD: The Initiator's static Diffie-Hellman P-256 key pair:
NEW: The Initiator's static Diffie-Hellman P-256 key pair consist of a private key and a public key.

4) <!--[rfced] In Sections 2.2, 2.5, 3.4, 3.5, 3.7, and 3.9, it seems there
are extraneous equals signs. Please review. For example, should the
second equals sign on the PRK_exporter line and PRK_out line
be removed (see c and d below)?

a) Original:
   PRK_2e = EDHOC_Extract( salt, G_XY ) =
          = HMAC-SHA-256( salt, G_XY )

Perhaps:
   PRK_2e = EDHOC_Extract( salt, G_XY )
          = HMAC-SHA-256( salt, G_XY )

b) Original: (appears in Sections 2.2 and 3.4)

   KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length ) =
               = HKDF-Expand( PRK_2e, info, plaintext_length )

Perhaps:
   KEYSTREAM_2 = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length )
               = HKDF-Expand( PRK_2e, info, plaintext_length )

c) Original: (appears in 3.7 and 3.9)

PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length ) =
             = HKDF-Expand( PRK_out, info,  hash_length )

Perhaps:
PRK_exporter = EDHOC_KDF( PRK_out, 10, h'', hash_length )
             = HKDF-Expand( PRK_out, info,  hash_length )


d) Original: (appears in 2.5 and 3.7)

PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length ) =
        = HKDF-Expand( PRK_4e3m, info,  hash_length )

Perhaps:
PRK_out = EDHOC_KDF( PRK_4e3m, 7, TH_4, hash_length )
        = HKDF-Expand( PRK_4e3m, info,  hash_length )


e) Original:
   OSCORE Master Secret =
   = HKDF-Expand(PRK_exporter, info, oscore_key_length)

Perhaps:
  OSCORE Master Secret
  = HKDF-Expand(PRK_exporter, info, oscore_key_length)

f) See more examples in Section 3.5: SALT_4e3m and PRK_4e3m
-->

John: Yes, please remove all the extraneous equals signs on the upper line.

5) <!--[rfced] The first lines of Sections 4.1.1-4.1.7, 4.2.1-4.2.6, 4.3.1,
and 4.3.2 are not complete sentences. Please review these instances and
let us know how they  may be updated.
-->

OLD: Invalid encoding of message_1 as array.
NEW: message_1 is incorrectly encoded as a CBOR array.

OLD: Invalid encoding 41 0e of C_I = 0x0e.
NEW: The connection identifier C_I = 0x0e is incorrectly encoded as the CBOR byte string 41 0e.

OLD: Invalid array encoding 81 02 of SUITES_I = 2
NEW: The element SUITES_I = 2 is incorrectly encoded as the CBOR array 81 02.

OLD: Invalid type of the third element (G_X).
NEW: The third element (G_X) is incorrectly encoded as a text string.

OLD: Invalid number of elements in the CBOR sequence.
NEW: The CBOR sequence has an incorrect number of elements.

OLD: Invalid encoding a1 04 42 32 10 of ID_CRED_R in PLAINTEXT_2.
NEW: The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the map a1 04 42 32 10.

OLD: Invalid encoding 41 32 of ID_CRED_R in PLAINTEXT_2.
NEW: The element ID_CRED_R in PLAINTEXT_2 is incorrectly encoded as the byte string 41 32.

OLD: Invalid length of the third element (G_X).
NEW: The third element (G_X) has an invalid length.

OLD: Invalid x-coordinate in G_X as x ≥ p.
NEW: The x-coordinate in G_X is invalid as x ≥ p.

OLD: Invalid x-coordinate in (G_X) not corresponding to a point on the P-256 curve.
NEW: The x-coordinate in (G_X) is invalid as it does not correspond to a point on the P-256 curve.

OLD: Curve25519 point of low order which fails the check for all-zero output according to Section 9.2 of [RFC9528].
NEW: The Curve25519 point is invalid as it is of low order and fails the check for all-zero output according to Section 9.2 of [RFC9528].

OLD: Invalid length of third element (Signature_or_MAC_2).
NEW: The third element (Signature_or_MAC_2) has an invalid length.

OLD: Invalid encoding of third element (G_X).
NEW: The third element (G_X) is incorrectly encoded.

OLD: Invalid 16-bit encoding 19 00 03 of METHOD = 3.
NEW: The element METHOD = 3 is incorrectly encoded as an 16-bit integer.

OLD: Invalid indefinite-length array encoding 9F 06 02 FF of SUITES_I = [6, 2].
NEW: The element SUITES_I = [6, 2] is incorrectly encoded as an indefinite-length array.

6) <!--[rfced] Citations

a) Section 4.1.2 - "0e" is not mentioned in Section 3.3.2 of RFC 9528.
(Please refer to https://www.rfc-editor.org/authors/rfc9528.html or
the other formats.) Please review and let us know if/how the citation
may be updated.

Original:
   Correct encoding is 0e
   according to Section 3.3.2 of [I-D.ietf-lake-edhoc].

NEW: The correct encoding is the integer 0e  according to Section 3.3.2 of [RFC9528].

b) Section 4.1.3 - "02" is not mentioned in Section 5.2.2 of RFC 9528.
Please review and let us know if/how the citation may be updated.

Original:
   Correct encoding is 02
   according to Section 5.2.2 of [I-D.ietf-lake-edhoc].

NEW: The correct encoding is the integer 02 according to Section 5.2.2 of [RFC9528].

c) Section 4.1.5 - "correct number of elements" is not mentioned in
Section 5.3.1 of RFC 9528. Please review and let us know if/how this
citation may be updated.

Original:
   Correct number of
   elements is 1 according to Section 5.3.1 of [I-D.ietf-lake-edhoc].

NEW: The  correct number of elements in the CBOR sequence is 1 according to Section 5.3.1 of [RFC9528].

d) Section 4.2.2 - "x < p" is not mentioned in Section 9.2 of RFC 9528.
Please let us know if/how this citation may be updated.

Original:
   Requirement that x < p
   according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
   of [SP-800-56A].

NEW: It is required that x < p according to Section 5.6.2.3 of [SP-800-56A], which is referenced in Section 9.2 of [RFC9528].

e) Section 4.2.3 - "y^2 ≡ x^3 + a ⋅ x + b (mod p)" is not mentioned in
Section 9.2 of RFC 9528. Please let us know if/how this citation may be
updated.

Original:
   Requirement that y^2 ≡ x^3 + a ⋅ x + b (mod p)
   according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
   of [SP-800-56A].

NEW: It is required that y^2 ≡ x^3 + a ⋅ x + b (mod p) according to Section 5.6.2.3 of [SP-800-56A], which is referenced in Section 9.2 of [RFC9528].

f) Section 4.2.6 - "leading zeros" is not mentioned in Section 3.7 of
RFC 9528. Please review and let us know if/how this citation may be
updated.

Original:
   Correct encoding is with
   leading zeros according to Section 3.7 of [I-D.ietf-lake-edhoc] and
   Section 7.1.1 of [RFC9053].

NEW: The correct encoding is with leading-zero octets according to Section 7.1.1 of [RFC9053], which is referenced in Section 3.7 of [RFC9528].

g) Section 4.3.2 - "82 06 02" is not mentioned in Section 5.2.2 of RFC 9528.
Please review and let us know if/how this citation may be updated.

Original:
   Correct encoding is 82 06 02 according to Section 5.2.2 of
   [I-D.ietf-lake-edhoc].
-->

NEW: The correct encoding is the definite-length array 82 06 02 according to Section 4.2.1 of [RFC8949], which is referenced in Section 5.2.2 of [RFC9528].

7) <!--[rfced] The first paragraphs of Sections 4.2.2  and 4.2.3 are made up of
incomplete sentences. Please review and let us know how they may be updated.

Original (Section 4.2.2):
   Invalid x-coordinate in G_X as x ≥ p.  Requirement that x < p
   according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3
   of [SP-800-56A].

Original (Section 4.2.3):
   Invalid x-coordinate in (G_X) not corresponding to a point on the
   P-256 curve.  Requirement that y^2 ≡ x^3 + a ⋅ x + b (mod p)
   according to Section 9.2 of [RFC9528] and Section 5.6.2.3
   of [SP-800-56A].
-->

NEW: The x-coordinate in G_X is invalid as x ≥ p. It is required that x < p according to Section 9.2 of [I-D.ietf-lake-edhoc] and Section 5.6.2.3 of [SP-800-56A].

NEW: The x-coordinate in (G_X) is invalid as it does not correspond to a point on the P-256 curve. It is required that y^2 ≡ x^3 + a ⋅ x + b (mod p) according to Section 9.2 of [RFC9528] and Section 5.6.2.3 of [SP-800-56A].

8) <!--[rfced] To improve readability, may we update this sentence as follows?

Original:
   Correct is the
   deterministic encoding 03 according to Section 3.1 of
   [I-D.ietf-lake-edhoc] and Section 4.2.1 of [RFC8949], which states
   that the arguments for integers, lengths in major types 2 through 5,
   and tags are required to be as short as possible.

Perhaps:
   The deterministic encoding 03 is correct according to Section 3.1 of
   [RFC9528] and Section 4.2.1 of [RFC8949], which states that the
   arguments for integers, lengths in major types 2 through 5, and tags
   are required to be as short as possible.
-->

John: Fine

9) <!--[rfced] FYI, we have moved one name in order to alphabetize
the names in the Acknowledgments because that seemed to have been
your intention. Please let us know if you prefer otherwise.
-->

John: Fine

10) <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Authenticated Encryption with Associated Data (AEAD)
Concise Binary Object Representation (CBOR)
Constrained Application Protocol (CoAP)
CBOR Object Signing and Encryption (COSE)
Diffie-Hellman (DH)
Elliptic Curve Diffie-Hellman (ECDH)
Edwards-curve Digital Signature Algorithm (EdDSA)
Message Authentication Code (MAC)
Object Security for Constrained RESTful Environments (OSCORE)
-->

John: Good

11) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

For example, please consider whether "master" should be updated.
-->

John: We have reviewed the “Inclusive Language” portion. “master” cannot be updated as it is the term used in RFC 8613.

Thank you.

RFC Editor/ap/ar


On Feb 29, 2024, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/02/29

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.

Planning your review
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor
  that have been included in the XML file as comments marked as
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors

  Please ensure that you review any changes submitted by your
  coauthors.  We assume that if you do not speak up that you
  agree to changes submitted by your coauthors.

*  Content

  Please review the full content of the document, as this cannot
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of
  content are correctly tagged.  For example, ensure that <sourcecode>
  and <artwork> are set correctly.  See details at
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the
  formatted output, as generated from the markup in the XML file, is
  reasonable.  Please note that the TXT will have formatting
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g.,
     IETF Stream participants are your working group chairs, the
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list
     to preserve AUTH48 conversations; it is not an active discussion
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you
       have dropped the address. When the discussion is concluded,
       [e-mail] will be re-added to the CC list and
       its addition will be noted at the top of the message.

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes.  Information about stream managers can be found in
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9529.xml
  https://www.rfc-editor.org/authors/rfc9529.html
  https://www.rfc-editor.org/authors/rfc9529.pdf
  https://www.rfc-editor.org/authors/rfc9529.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9529-diff.html
  https://www.rfc-editor.org/authors/rfc9529-rfcdiff.html (side by side)

Diff of the XML:
  https://www.rfc-editor.org/authors/rfc9529-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9529

Please let us know if you have any questions.

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9529 (draft-ietf-lake-traces-09)

Title            : Traces of EDHOC
Author(s)        : G. Selander, J. Mattsson, M. Serafin, M. Tiloca, M. Vučinić
WG Chair(s)      : Mališa Vučinić, Stephen Farrell
Area Director(s) : Roman Danyliw, Paul Wouters

John: My last name is fine in the document but here it is chopped in half. My last name is “Preuß Mattsson” including the white space.