Re: [auth48] AUTH48: RFC-to-be 9459 <draft-ietf-cose-aes-ctr-and-cbc-06> for your review

[Megan Ferguson <[e-mail]>]

Hi Russ and Hannes,

Thank you for your replies.  We have updated the document as requested and updated the email for Hannes and Mike in our database entry for this document as well.

Russ - please note that we have made the update requested to Section 6, but this is directly related to one of the questions (9b) we sent on 8/11 (copied below this message for your convenience).  Please let us know if any further updates to this text or related text are necessary.

  The files have been posted here:
   https://www.rfc-editor.org/authors/rfc9459.txt
   https://www.rfc-editor.org/authors/rfc9459.pdf
   https://www.rfc-editor.org/authors/rfc9459.html
   https://www.rfc-editor.org/authors/rfc9459.xml

  The diff files have been posted here: 
   https://www.rfc-editor.org/authors/rfc9459-diff.html (comprehensive diff)
   https://www.rfc-editor.org/authors/rfc9459-alt-diff.html (comprehensive diff accommodating text movement)
   https://www.rfc-editor.org/authors/rfc9459-rfcdiff.html (comprehensive side-by-side diff)
   https://www.rfc-editor.org/authors/rfc9459-auth48diff.html (AUTH48 changes only)

Thank you.

RFC Editor/mf

------
Copy of the document-specific questions:

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. -->


2) <!--[rfced] Might this list be easier to read with bulleted formatting?

Original:
Data is encrypted and decrypted by XORing with the key stream produced
by AES encrypting sequential IV block values, called counter
blocks.  The first block of the key stream is the AES encryption of the
IV, the second block of the key stream is the AES encryption of (IV +
1) mod 2^128, the third block of the key stream is the AES encryption
of (IV + 2) mod 2^128, and so on.

Perhaps:
Data is encrypted and decrypted by XORing with the key stream produced
by AES encrypting sequential IV block values, called "counter blocks",
where:

* The first block of the key stream is the AES encryption of the IV.

* The second block of the key stream is the AES encryption of (IV + 1)
mod 2^128.

* The third block of the key stream is the AES encryption of (IV + 2)
mod 2^128, and so on.

-->


3) <!--[rfced] We had two questions regarding the last sentence that
    appears in both Sections 4.1 and 5.1:

Original:
In addition, the 'protected' header parameters encoded value MUST be a
zero-length byte string.

a) Should "parameters" be possessive (i.e., parameter's or
parameters')?  Or perhaps a rewrite to "...the encoded value of the
'protected' header parameter MUST be a zero-length byte string."?

b) Please confirm that this sentence should not be part of the
bulleted list that appears above it.

-->


4) <!--[rfced] Please note that we have updated the mention of the
    entries in the "Change Controller" column of the "COSE
    Algorithms" registry to use "IETF" per this IANA note:

NOTE: This document's IANA Considerations section says that "the
'Change Controller' column should contain 'IESG'," but the IESG
prefers that the IETF be listed in the change controller field instead
(unless the RFC that created the registry requires otherwise, as in
the IETF XML and port/service name registries). We've listed "IETF" as
the change controller here.

-->


5)  <!--[rfced] We had two questions related to the following sentence:

a) How does "guess of 16 bytes of plaintext at a time" relate to the
rest of the sentence?  Is text missing here?

Original:
An attacker can switch the algorithm identifier from AES-GCM to AES-
CBC, guess of 16 bytes of plaintext at a time, and checking each guess
with padding oracle as discussed above.

Perhaps (note - further updates to this sentence suggested in b) below):
An attacker can switch the algorithm identifier from AES-GCM to AES-
CBC by using guesses of 16 bytes of plaintext at a time and then checking
each guess with padding oracle as discussed above.

b) Please clarify "checking each guess with padding oracle".  Based on
the earlier text in the section, we are wondering if this text should
possibly read as suggested below:

Text earlier in the section:
  With AES-CBC mode, implementers should perform integrity checks prior
  to decryption to avoid padding oracle vulnerabilities [Vaudenay].

Perhaps:
An attacker can switch the algorithm identifier from AES-GCM to AES-
CBC by using guesses of 16 bytes of plaintext at a time and then
integrity checking each guess to avoid padding oracle vulnerabilities
(as discussed above).


-->


6) <!-- [rfced] This reference has been superseded by a newer version; see
https://csrc.nist.gov/pubs/fips/197/final. Would you like to cite the
most current version?

Original:
  [AES]      National Institute of Standards and Technology (NIST),
             "Advanced Encryption Standard (AES)", FIPS
             Publication 197, November 2001.

Current:
  [AES]      National Institute of Standards and Technology (NIST),
             "Advanced Encryption Standard (AES)", NIST FIPS 197,
             DOI 10.6028/NIST.FIPS.197, November 2001,
             <https://doi.org/10.6028/NIST.FIPS.197>.

Perhaps:	      
  [AES]      National Institute of Standards and Technology (NIST),
             "Advanced Encryption Standard (AES)", NIST FIPS 197,
             DOI 10.6028/NIST.FIPS.197-upd1, May 2023,
             <https://doi.org/10.6028/NIST.FIPS.197-upd1>.
-->


7) <!-- [rfced] FYI - We updated the citation tag for this reference entry from
"[IANA]" to "[IANA-COSE]" to indicate the registry. Let us know any
objections.

Original:
  [IANA]     "IANA Registry for CBOR Object Signing and Encryption
             (COSE)", n.d.,
             <https://www.iana.org/assignments/cose/cose.xhtml>.

Current:	      
  [IANA-COSE]
             IANA, "CBOR Object Signing and Encryption (COSE)",
             <https://www.iana.org/assignments/cose>.
-->


8) <!--[rfced] We had the following questions/comments regarding this
    document's XML formatting:

a) Please review each artwork element in the xml file. Specifically,
should the artwork elements in Section 8 be tagged as sourcecode?

b) FYI - We have used the <sup> element for superscript 
in this document. You can see how it looks in Sections 4 and 8.

Note: In the HTML and PDF, it appears as superscript. In the text
output, <sup> generates a^b, which was used in the original document.
-->


9) <!-- [rfced] Please review the following terminology questions/comments:

a) FYI - We see both of the following expansions used in the
document. We updated to the latter (i.e., expansion with
"Associated").  Please let us know any objections.

authenticated encryption with additional data (AEAD)
Authenticated Encryption with Associated Data (AEAD)

b) We made the capping scheme "Content Encryption algorithms" be used
consistently in this document (as there was only a single instance
where lowercase was used), but we note that the lowercase form
"content encryption algorithm" is used in RFC 9052 (normatively
referenced by this document) and other COSE documents like RFCs 9053
and 8152. Please review and let us know if any updates are needed.

c) We see field names in single quotes.  Please note that we applied
this treatment to 'kid' field as well.  Please review.

d) Please review the following update to expand AES-CTR without
including "mode" in the abbreviation.  We have seen use in past RFCs
both with and without "mode" inside the expansion, but based on the
other uses in this document, removing mode from the expansion seemed
consistent. Please let us know objections or any necessary further
changes.

Original:
Only AES Counter mode (AES-CTR) and AES Cipher Block Chaining (AES-
CBC) are discussed in this document.

Current:
Only AES Counter (AES-CTR) mode and AES Cipher Block Chaining
(AES-CBC) are discussed in this document.

Examples of other uses:

Original:
When used properly, AES-CTR mode provides strong confidentiality.

Original:
Data forgery is trivial with AES-CTR mode.

Original:
4.  AES Counter Mode


e) For the following abbreviations, we will update to use the
abbreviated form after first use (i.e., remove the expansions or
update from the expanded form to the abbreviation) per the guidance at
https://www.rfc-editor.org/styleguide/part2/ unless we hear objection.

Initialization Vector (IV)
Authenticated Encryption with Associated Data (AEAD)
Additional Authenticated Data (AAD)
-->


10) <!-- [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 "his" should be updated: 

Original:
If a known plaintext octet sequence P1, P2, P3 is encrypted with key
stream K1, K2, K3, then the attacker can replace the plaintext with
one of his own choosing.

-->


Thank you.

RFC Editor/kf/mf

> On Aug 16, 2023, at 7:54 AM, Hannes Tschofenig <[e-mail]> wrote:
> 
> Thanks, Russ. 
> 
> 
> Thanks for the editing work on this document. Here are some quick comments:
> 
> Please change my contact information
> 
> FROM:
> Hannes Tschofenig
> Arm Limited
> Email: [e-mail]
> 
> TO:
> Hannes Tschofenig
> Email: [e-mail]
> 
> 
> Please change the text in the acknowledgment section. I noticed that we forgot to mention a few reviewers.
> 
> FROM:
> Many thanks to David Brown for raising the need for non-AEAD algorithms to support encryption within the SUIT manifest. Many thanks to David Brown, Ilari Liusvaara, Scott Arciszewski, John Preuß Mattsson, Laurence Lundblade, Paul Wouters, Roman Danyliw, and John Scudder for the review and thoughtful comments.
> 
> TO:
> Many thanks to David Brown for raising the need for non-AEAD algorithms to support encryption within the SUIT manifest. Many thanks to Ilari Liusvaara, Scott Arciszewski, John Preuß Mattsson, Laurence Lundblade, Paul Wouters, Roman Danyliw, Sophie Schmieg, Stephen Farrell, Carsten Bormann, Scott Fluhrer, Brendan Moran, and John Scudder for the review and thoughtful comments.
> 
> 
> In the security consideration section please change the following sentence
> 
> FROM:
> 
> The use of the ciphers is limited to special use cases where integrity and authentication is provided by another mechanism, such as firmware encryption.
> 
> TO:
> 
> The use of the ciphers is limited to special use cases, such as firmware encryption, where integrity and authentication is provided by another mechanism.
> 
> Ciao
> Hannes
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Russ Housley <[e-mail]>
>> Gesendet: Dienstag, 15. August 2023 15:29
>> An: RFC Editor <[e-mail]>
>> Cc: Hannes Tschofenig <[e-mail]>; [e-mail]; Cose
>> Chairs Wg <[e-mail]>; Mike Jones
>> <[e-mail]>; Paul Wouters <[e-mail]>;
>> [e-mail]
>> Betreff: Re: AUTH48: RFC-to-be 9459 <draft-ietf-cose-aes-ctr-and-cbc-06> for
>> your review
>> 
>> Resending with good email addresses for Hannes and Mike.
>> 
>> Russ
>> 
>>> On Aug 15, 2023, at 9:22 AM, Russ Housley <[e-mail]> wrote:
>>> 
>>> Section 5.1: please lower case content encryption to match usage in RFC 9052.
>>> 
>>> OLD
>>> 
>>> non-AEAD Content Encryption algorithms
>>> 
>>> NEW
>>> 
>>> non-AEAD content encryption algorithms
>>> 
>>> Russ
>>> 
>>> 
>>>> On Aug 11, 2023, at 2:41 PM, [e-mail] wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2023/08/11
>>>> 
>>>> 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-4Q9l2USx
>>>> IAe6P8O4Zc
>>>> 
>>>>   *  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/rfc9459.xml
>>>> https://www.rfc-editor.org/authors/rfc9459.html
>>>> https://www.rfc-editor.org/authors/rfc9459.pdf
>>>> https://www.rfc-editor.org/authors/rfc9459.txt
>>>> 
>>>> Diff file of the text:
>>>> https://www.rfc-editor.org/authors/rfc9459-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9459-rfcdiff.html (side by
>>>> side)
>>>> 
>>>> Diff of the XML:
>>>> https://www.rfc-editor.org/authors/rfc9459-xmldiff1.html
>>>> 
>>>> For your convenience, we have also created an alt-diff file that will
>>>> allow you to more easily view changes where text has been deleted or
>>>> moved:
>>>> http://www.rfc-editor.org/authors/rfc9459-alt-diff.html
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> https://www.rfc-editor.org/auth48/rfc9459
>>>> 
>>>> Please let us know if you have any questions.
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9459 (draft-ietf-cose-aes-ctr-and-cbc-06)
>>>> 
>>>> Title            : CBOR Object Signing and Encryption (COSE): AES-CTR and AES-
>> CBC
>>>> Author(s)        : R. Housley, H. Tschofenig
>>>> WG Chair(s)      : Matthew A. Miller, Ivaylo Petrov, Michael B. Jones
>>>> 
>>>> Area Director(s) : Roman Danyliw, Paul Wouters
>>>> 
>>>> 
>>> 
> 
>