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

[Megan Ferguson <[e-mail]>]

Hi Hannes,

Thank you for resending.

We have incorporated this change into our files posted below.  Once we have your approval of the document in this form, we will be able to move forward in the publication process.

  The files have been posted here (please refresh):
   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 relevant diff files have been posted here (please refresh):
   https://www.rfc-editor.org/authors/rfc9459-diff.html (comprehensive diff)
   https://www.rfc-editor.org/authors/rfc9459-rfcdiff.html (comprehensive side-by-side)
   https://www.rfc-editor.org/authors/rfc9459-auth48diff.html (all AUTH48 changes)
   https://www.rfc-editor.org/authors/rfc9459-lastdiff.html (last version to this)
   https://www.rfc-editor.org/authors/rfc9459-lastrfcdiff.html (last version to this side-by-side)

  The AUTH48 status page is viewable here:
   https://www.rfc-editor.org/auth48/rfc9459

Thank you.

RFC Editor/mf


> On Sep 10, 2023, at 8:04 AM, Hannes Tschofenig <[e-mail]> wrote:
> 
> Hi Megan,
> 
> 
> I believe my email sent Monday this week didn't get transmitted. I am
> resending it.
> 
> 
> This version works for me:
> "
> An attacker can switch the algorithm identifier from AES-GCM to AES-CBC,
> guessing 16 bytes of plaintext at a time, and see if the recipient
> accepts the padding. Padding oracle vulnerabilities are discussed
> further in [Vaudenay].
> "
> 
> 
> Ciao
> Hannes
> 
> Am 05.09.2023 um 22:28 schrieb Megan Ferguson:
>> Hi Hannes,
>> 
>> Thanks for the reply.
>> 
>> This update would address our question 5b.  But it looks like 5a might still be problematic.
>> 
>> The question and your responses are copied below for convenience:
>> 
>> 
>> 
>>> 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).
>>> 
>>> 
>>> 
>>> I need to re-read [Vaudenay] to propose better text.
>>> 
>>> An attacker can switch the algorithm identifier from AES-GCM to AES-CBC,
>>> guess of 16 bytes of plaintext at a time, and see if the recipient
>>> accepts the
>>> padding. Padding oracle vulnerabilities are discussed further in [Vaudenay].
>> 
>> [rfced] Might we further update to something like:
>> 
>> An attacker can switch the algorithm identifier from AES-GCM to AES-CBC,
>> [making/using] a guess of 16 bytes of plaintext at a time, and see if the recipient
>> accepts the padding. Padding oracle vulnerabilities are discussed further in [Vaudenay].
>> 
>> Or perhaps:
>> 
>> An attacker can switch the algorithm identifier from AES-GCM to AES-CBC,
>> guessing 16 bytes of plaintext at a time, and see if the recipient
>> accepts the padding. Padding oracle vulnerabilities are discussed further in [Vaudenay].
>> 
>> If none of these fit the bill, please let us know how we can rephrase.
>> 
>> Thank you.
>> 
>> RFC Editor/mf
>> 
>> 
>> 
>> 
>> 
>>> On Sep 4, 2023, at 9:30 AM, Hannes Tschofenig <[e-mail]> wrote:
>>> 
>>> Hi Megan,
>>> 
>>> 
>>> here is the suggested text for #5:
>>> 
>>> 
>>> "
>>> 
>>> An attacker can switch the algorithm identifier from AES-GCM to AES-CBC,
>>> guess of 16 bytes of plaintext at a time, and see if the recipient
>>> accepts the
>>> padding. Padding oracle vulnerabilities are discussed further in [Vaudenay].
>>> 
>>> "
>>> 
>>> 
>>> Ciao
>>> 
>>> Hannes
>>> 
>>> 
>>> Am 23.08.2023 um 21:21 schrieb Megan Ferguson:
>>>> Hannes,
>>>> 
>>>> Thank you for your reply and guidance.
>>>> 
>>>> We have updated the files as suggested, added your suggested keywords to our database, and reposted the files.
>>>> 
>>>> Note that we will await your reply regarding question #5 prior to moving this document forward in the publication process.
>>>> 
>>>>   The files have been posted here (please refresh):
>>>>    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 relevant diff files have been posted here (please refresh):
>>>>    https://www.rfc-editor.org/authors/rfc9459-diff.html (comprehensive)
>>>>    https://www.rfc-editor.org/authors/rfc9459-rfcdiff.html (comprehensive side-by-side)
>>>>    https://www.rfc-editor.org/authors/rfc9459-auth48diff.html (all AUTH48 changes)
>>>>    https://www.rfc-editor.org/authors/rfc9459-lastdiff.html (last version to this)
>>>>    https://www.rfc-editor.org/authors/rfc9459-lastrfcdiff.html (last version to this side-by-side)
>>>> 
>>>>   The AUTH48 status page for this document is viewable here:
>>>>    https://www.rfc-editor.org/auth48/rfc9459
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/mf
>>>> 
>>>> 
>>>>> On Aug 22, 2023, at 12:24 AM, Hannes Tschofenig <[e-mail]> wrote:
>>>>> 
>>>>> Hi Megan,
>>>>> 
>>>>> 
>>>>> 
>>>>> Let me try to answer the questions below.
>>>>> 
>>>>> 
>>>>> 
>>>>> Am 21.08.2023 um 19:15 schrieb Megan Ferguson:
>>>>>> Hi Russ,
>>>>>> 
>>>>>> Thank you for your reply.  We have marked your approval at the AUTH48 status page (see
>>>>>> https://www.rfc-editor.org/auth48/rfc9459
>>>>>> ).  We will assume your assent to any further changes from your coauthor unless we hear objection at that time.
>>>>>> 
>>>>>> We will await word from Hannes as well as responses to the the author queries we sent on August 11 prior to moving this document forward in the publication process.
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/mf
>>>>>> 
>>>>>> 
>>>>>>> On Aug 19, 2023, at 5:44 AM, Russ Housley <[e-mail]>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Thank you.  It is ready to publish.
>>>>>>> 
>>>>>>> Russ
>>>>>>> 
>>>>>>> 
>>>>>>>> On Aug 18, 2023, at 6:38 PM, Megan Ferguson <[e-mail]>
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> . -->
>>>>>>>> 
>>>>> I would add these two keywords:
>>>>> 
>>>>> - COSE Encryption
>>>>> 
>>>>> - Firmware encryption
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> -->
>>>>>>>> 
>>>>> Using the bullet list works for me.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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."?
>>>>>>>> 
>>>>> I think it is better to change the sentence
>>>>> 
>>>>> 
>>>>> 
>>>>> FROM:
>>>>> 
>>>>> In addition, the 'protected' header parameters encoded value MUST be a zero-length byte string.
>>>>> 
>>>>> 
>>>>> 
>>>>> TO:
>>>>> 
>>>>> 
>>>>> 
>>>>> "The 'protected' header 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.
>>>>>>>> 
>>>>>>>> 
>>>>> The placement is a bit confusing. I believe it would be better to move the sentence one paragraph up.
>>>>> 
>>>>> Hence, instead of putting the sentence to the end of Section 4.1 move it right before the Section 4.1 heading.
>>>>> 
>>>>> Same is true for Section 5.1.
>>>>> 
>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> -->
>>>>>>>> 
>>>>>>>> 
>>>>> IETF as change controller is fine.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>> I need to re-read [Vaudenay] to propose better text.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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>
>>>>>>>> .
>>>>>>>> -->
>>>>>>>> 
>>>>> I would reference the latest version, published in May 2023.
>>>>> 
>>>>>>>> 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>
>>>>>>>> .
>>>>>>>> -->
>>>>>>>> 
>>>>> Works for me.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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?
>>>>>>>> 
>>>>> I wouldn't tag the text in Section 8 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.
>>>>>>>> -->
>>>>>>>> 
>>>>> This looks great. Thanks
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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)
>>>>>>>> 
>>>>> Please use "Authenticated Encryption with Associated Data (AEAD)" since RFC 9052 / 9053 use it as well.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>> Please use us "content encryption algorith" to stay inline with RFC 9052 etc.
>>>>>>>> c) We see field names in single quotes.  Please note that we applied
>>>>>>>> this treatment to 'kid' field as well.  Please review.
>>>>>>>> 
>>>>> Thanks for the change. Being consistent is good.
>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>> The proposed text with
>>>>> 
>>>>> "
>>>>> 
>>>>> Only AES Counter (AES-CTR) mode and AES Cipher Block Chaining (AES-CBC) are discussed in this document.
>>>>> "
>>>>> 
>>>>> is better.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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)
>>>>>>>> -->
>>>>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> -->
>>>>>>>> 
>>>>> I will re-read the document but regarding this specific sentence please change it to:
>>>>> 
>>>>> "
>>>>> 
>>>>>    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 its own choosing.
>>>>> 
>>>>> 
>>>>> "
>>>>> 
>>>>> 
>>>>> 
>>>>> Ciao
>>>>> Hannes
>>>>> 
>>>>> 
>>>>> 
>>>>>>>> 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
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>