[{"author": "Carsten Bormann", "text": "

1, 2, 3, testing

", "time": "2022-07-26T17:32:51Z"}, {"author": "Michael Prorock", "text": "

I see carsten testing

", "time": "2022-07-26T17:35:30Z"}, {"author": "John Preu\u00df Mattsson", "text": "

1, 2, 3, testing

", "time": "2022-07-26T17:35:38Z"}, {"author": "Carsten Bormann", "text": "

/me ducks

", "time": "2022-07-26T17:35:59Z"}, {"author": "Thomas Fossati", "text": "

gnitset ,3 ,2 ,1

", "time": "2022-07-26T17:36:22Z"}, {"author": "Carsten Bormann", "text": "

+1

", "time": "2022-07-26T17:37:29Z"}, {"author": "Christian Ams\u00fcss", "text": "

meetecho: Please pan

", "time": "2022-07-26T17:41:57Z"}, {"author": "John Preu\u00df Mattsson", "text": "

So the question is basically to use the format in HPKE or the format used in COSE...

", "time": "2022-07-26T17:46:17Z"}, {"author": "Christian Ams\u00fcss", "text": "

... the format in HPKE libraries. (That happens a lot with other primitives, where libraries only implement special encodings).

", "time": "2022-07-26T17:46:57Z"}, {"author": "John Preu\u00df Mattsson", "text": "

I think this is limited to libraries. The HPKE RFC states \" For P-256, P-384, and P-521, the SerializePublicKey() function of the
\n KEM performs the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to [SECG].\"

", "time": "2022-07-26T17:50:05Z"}, {"author": "John Preu\u00df Mattsson", "text": "

\"Standard representation\" is probably not the best wording as the 65 byte SECG encoding is a much older standard and far more used.

", "time": "2022-07-26T17:52:18Z"}, {"author": "Brendan Moran", "text": "

Not practical

", "time": "2022-07-26T17:54:19Z"}, {"author": "Carsten Bormann", "text": "

Is there nothing else protected by the AEAD?

", "time": "2022-07-26T17:54:37Z"}, {"author": "Carsten Bormann", "text": "

(in this case)

", "time": "2022-07-26T17:54:59Z"}, {"author": "Brendan Moran", "text": "

To be clear: It is not practical to require integrity verification prior to decryption. I'll make a comment at the mic.

", "time": "2022-07-26T17:55:25Z"}, {"author": "G\u00f6ran Selander", "text": "

We could set the \"Recommended\" column in the IANA registry to \"No\" to inidicate the caveat with encryption without integrity protection.

", "time": "2022-07-26T17:57:01Z"}, {"author": "Brendan Moran", "text": "

Ugh, I dropped the audio connection

", "time": "2022-07-26T17:57:52Z"}, {"author": "Brendan Moran", "text": "

Back now

", "time": "2022-07-26T17:57:54Z"}, {"author": "Benjamin Kaduk", "text": "

W.r.t. Carsten's question about AAD, we also need to be careful about that, yes. In particular, the \"alg\" parameter itself will not be authenticated, which requires some additional security considerations discussion.

", "time": "2022-07-26T18:00:23Z"}, {"author": "Brendan Moran", "text": "

I appreciate that this is a very complex issue and that the need to ensure minimisation of foot-guns is important. Firmware update is a very special case.

", "time": "2022-07-26T18:02:12Z"}, {"author": "Benjamin Kaduk", "text": "
\n

alg:
\nThis header parameter is used to indicate the algorithm used for the security processing. This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (e.g., COSE_Sign and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected-header-parameters bucket or as part of the externally supplied data (Section 4.3).

\n
", "time": "2022-07-26T18:03:01Z"}, {"author": "Brendan Moran", "text": "

The SUIT use case may not be as special as it sounds, however, this is just a streaming decryption requirement. I would ask if it is in scope to make a streaming decryption mechanism for COSE Encrypt.

", "time": "2022-07-26T18:03:52Z"}, {"author": "Benjamin Kaduk", "text": "

There is some text in 8152bis-struct about (non-)support for streaming signature processing.

", "time": "2022-07-26T18:04:40Z"}, {"author": "Benjamin Kaduk", "text": "

Oops, apparently I mean 8152bis-algs.

", "time": "2022-07-26T18:05:03Z"}, {"author": "Benjamin Kaduk", "text": "
\n

For EdDSA, the content to be signed (either the message or the prehash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. Therefore, there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory.

\n
", "time": "2022-07-26T18:06:00Z"}, {"author": "Brendan Moran", "text": "

Benjamin Kaduk said:

\n
\n
\n

For EdDSA, the content to be signed (either the message or the prehash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. Therefore, there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory.
\n

\n
\n
\n

Even then, this text is specific to EdDSA. It also provides an explicit mechanism for handling the message if it doesn't fit in EdDSA with single-pass processing.

", "time": "2022-07-26T18:08:15Z"}, {"author": "John Preu\u00df Mattsson", "text": "

I don't think this is limited to SUIT at all. There are many other uses cases where IND-CPA encryption is a good choice and the integrity protection does not provide much (or nothing). One recent example is the header encryption in DTLS/QUIC, another is the the second flight in the SIGMA-I protocol (used in EDHOC), and a third example is many/most/all use cases where COSE countersign is used, e.g. Group OSCORE.

\n

The drive to move all security protocol to AEAD was very good but was like many other things driven a bit to far. IND-CPA encryption still have uses.

", "time": "2022-07-26T18:08:34Z"}, {"author": "Brendan Moran", "text": "

For SUIT, I think there's another possibility: block AEAD. This is either shared key, different init-vector, or shared init vector with KDF from a single key. However, I don't think that existing COSE structures would support that use.

", "time": "2022-07-26T18:10:35Z"}, {"author": "Brendan Moran", "text": "

I'm curious how these options would fit with existing libraries.

", "time": "2022-07-26T18:12:20Z"}, {"author": "Benjamin Kaduk", "text": "

Applications would be free to use it, and there would be ambiguity about what the application means by doing so.

", "time": "2022-07-26T18:15:42Z"}, {"author": "Brendan Moran", "text": "

@Carsten Bormann If you're using SUIT, you have a different solution for nbf...

", "time": "2022-07-26T18:16:10Z"}, {"author": "Brendan Moran", "text": "

Benjamin Kaduk said:

\n
\n

Applications would be free to use it, and there would be ambiguity about what the application means by doing so.

\n
\n

Granted; I think it would have to be a new algorithm because the way it's used is substantially different.

", "time": "2022-07-26T18:17:53Z"}, {"author": "Benjamin Kaduk", "text": "

(for context, the \"it\" I meant was the proposed COSE header parameter that contains CWT claims)

", "time": "2022-07-26T18:19:19Z"}, {"author": "Brendan Moran", "text": "

Benjamin Kaduk said:

\n
\n

(for context, the \"it\" I meant was the proposed COSE header parameter that contains CWT claims)

\n
\n

Oops, sorry, I assumed the wrong thing!

", "time": "2022-07-26T18:19:54Z"}, {"author": "Benjamin Kaduk", "text": "

I think I was typing too fast and didn't proofread, sorry.

", "time": "2022-07-26T18:20:25Z"}, {"author": "Armando Faz-Hern\u00e1ndez", "text": "

none of the PQ signatures algorithms has been settled down.

", "time": "2022-07-26T18:23:13Z"}, {"author": "Mike Ounsworth", "text": "

+1 for getting the drafts started, adopted, etc, and then pause them until NIST finalizes.

", "time": "2022-07-26T18:24:21Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Mike Ounsworth said:

\n
\n

+1 for getting the drafts started, adopted, etc, and then pause them until NIST finalizes.

\n
\n

+1

", "time": "2022-07-26T18:24:43Z"}, {"author": "Carsten Bormann", "text": "

As long as \"starting\" the draft doesn't stop us later to apply things we have learned, +1, too

", "time": "2022-07-26T18:27:41Z"}, {"author": "Brendan Moran", "text": "

@John, it's not necessary for these targets: hybrid with signatures is just multiply-signed

", "time": "2022-07-26T18:28:29Z"}, {"author": "Brendan Moran", "text": "

Or am I missing something?

", "time": "2022-07-26T18:30:06Z"}, {"author": "John Preu\u00df Mattsson", "text": "

LMS is already standardized in COSE..... is something missing?

", "time": "2022-07-26T18:30:22Z"}]