On Tue, Feb 25, 2025 at 08:05:50PM +0000, Steve Lasker wrote: > Hi, Ilari, thanks for the feedback. > We discussed in meeting today, incorporating several changes > https://github.com/cose-wg/draft-ietf-cose-hash-envelope/pull/45, and > provided some answers below. > Please let us know if you have any more feedback. > Steve > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Friday, February 21, 2025 11:22 AM > To: [email protected] > Subject: [COSE] Re: I-D Action: draft-ietf-cose-hash-envelope-02.txt > > On Fri, Feb 21, 2025 at 09:40:22AM -0800, [email protected] wrote: > > Internet-Draft draft-ietf-cose-hash-envelope-02.txt is now available. > > It is a work item of the CBOR Object Signing and Encryption (COSE) WG of > > the IETF. > > > > Title: COSE Hash Envelope > > Authors: Orie Steele > > Steve Lasker > > Henk Birkholz > > Name: draft-ietf-cose-hash-envelope-02.txt > > Pages: 11 > > Dates: 2025-02-21 > > Some comments from looking through the diff (some are repeats): > > > - Why preimage content type may be unprotected? That seems like attack vector > to me. > > As content_type is listed in generic headers, within RFC9052, we want > to be consistent, and don't intend to make changes.
Ugh. RFC 9052 does not even seem to recommend protecting content-type. > - Why payload-location has to be protected? That does not seem so critical. > The payload will be integerity-checked anyway. > > The authors and editor discussed and decided the payload_location > should be treated the same as pre-image-content-type. We would like to add > instructions for processing the pre-image-content-type and location, > regardless of where they are present. Payload_location does not affect message processing, whereas content_type does. > - There should be (protected) parameter to store preimage length to assist in > safely fetching the payload. > > Are you suggesting we add another size header? Yes. Obviously it should be protected, and messages that have it also should have payload_location. > - Payload-location SHOULD NOT be present in hash-envelope messages with > detached payload. > > Detached payloads are part of RFC9052, we discussed and disagree we > should make any additional statement in this draft. > > - If application supplies detached payload, signature verification SHOULD > apply the indicated hash algorithm to it. If the result does not match > included payload, the signature MUST be rejected, otherwise the result is > used as payload in signature verification. > > This draft doesn't propose changing the semantics of cosesign_1. > CoseSign1 supports attached and detached payloads. I see two ways of using hash envelopes: 1) Standing in for some very large file that is available from somewhere else. The payload is attached and payload_location is presumably set. In this case, after verifying the signature, the application is supposed to fetch the payload and use the attached hash to verify its integerity. This mode has been presented as motivation for hash envelopes in various presentations. 2) To sign large detached payloads without using pre-hash signatures. The payload is detached and there is no payload_location. In this case, the detached payload supplied by application needs to be hashed and used as payload in signature verification (if there already is attached payload, it obviously must match, or the signature is going to fail anyway). I don't offhand remember if this mode has been in any presentations. The latter is about transparently handling the second case. > - The draft mentions COSE_Encrypt. What do these paremeters mean in context > of COSE_Encrypt? And the whole section looks like something that should be > subsection of Security Considerations. > > PR #45 moves Encrypted Hashes into the security considerations. What should an application do with COSE_Encrypt message that contains payload_hash_alg? > - The security considerations mention pre-hashed signature algorithms. This > mechanism SHOULD NOT be used with pre-hashed signatures (unless the algorithm > is inherently pre-hashed, e.g., ECDSA), and SHOULD instead be used as > alternative to pre-hashing. > > CoseSign1 secures the entire signature1 structure. We believe this is > acceptable, even in the presence of pre-hash signature algorithms that might > be registered in the future. > > - The draft mentions Ed25519ph, which is not supported in COSE at all, and > HashML-DSA, which is inherently problematic to support in COSE (the current > plan for ML-DSA in COSE assumes that HashML-DSA is NOT supported). > > You're correct. We were asked to add, reluctantly added, but we'll > remove mentions Ed25519ph and HashML-DSA. > COSE Algorithms for Two-Party Signing > (https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-00.html) > has more info if desired. Pre-hash signatures have inherit problems. The second use of hash envelopes above is to avoid using signature pre-hashing. LAMPS WG had an extensive discussion about HashML-DSA, and concluded that it is more trouble than it is worth, even for CMS, where payloads can be large (the "Two-Party Signing" is solved by using external mu). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
