Hi Steve, So just to be clear, the denial of service (DOS) attack is caused by attempting to resolve a file or byte stream of arbitrary length?
And the solution is to believe the issuer has accurately reflected the length of the pre-image and the location and content type hints? Does this consideration apply to any other URIs present in the header? Such as x5u? Depending on the URI or string and resolver software, the transfer could start, and then hang... Forever. The client could retry, the client might not even need to resolve the resource because of caching or having previously dereferenced the resource. The resource could be compressed, have different transfer encoding, etc... There are a lot of reasons that the original file might not be resolvable to the signed hash, and a lot of ways to handle resolution which could result in unreasonable amount of work for a client or a server. I don't see how any of that is this drafts business. I can see how certain application use cases might rely on additional metadata in the protected header or unprotected header (such as a counter signature, or time stamp token), before attempting to use the verified payload and header parameters. You assert that a complete scenario requires downloading the original content. I believe that's where we disagree. I could send you a hash envelope, you could already have the content, you could compute the hash of it, and attach it as the payload, and verify the signature. Every use of a hash envelope with a detached payload, starts with you computing the hash, and then verifying the signature. This is also how you would use hash envelope to verify a signature for some expected hardware/firmware measurement. You might have JWK/COSE Key... The hash is the cose key thumbprint... The signature proves its still trusted. When I share with you a signature for a package URL, I'm not requiring you to download it. Package URLs don't include a size parameter. When I share with you a signed container layer, I'm not requiring you to download it, or even to necessarily rebuild and confirm the hash matches. If I'm hashing a large file or local configuration or tripwire system, and uploading hash envelopes, the server won't naturally have access to the original files, which could be sensitive, or unsuitable for transport over the network. The server doesn't care what the size of the file is, it won't ever see the original content. This is the SCITT use case for creating transparency around local LLM models, or other content that can't be transferred to the transparency service. Perhaps your intended use case is similar to git lfs? ``` $ git lfs pointer --file=path/to/file Git LFS pointer for path/to/file: version https://git-lfs.github.com/spec/v1 oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393 size 12345 ``` If you know, that the size will always be present, you can sum over every pointer to compute the total size of stored objects. Perhaps we should consider a version parameter as well? Where is the download use case you are describing actually coming from? Given that location and content type are already optional, how can you argue that lack of size makes the draft incomplete? I'm not sure if I'll be available to attend the session at IETF 122, I'm hoping we can discuss the essential remaining blockers for this draft on list. Regards, OS On Thu, Mar 6, 2025, 1:40 PM Steve Lasker <[email protected]> wrote: > > What happens if the resolved file has the correct hash, but incorrect > file size? > > Fail transfer as soon as incorrect size is received (as soon as HTTP > Content-Length is received, when file cuts off prematurely, or file > continues past where it should end). > I'd agree fail is the expected outcome, if the actual length is either too > small or too big. > > > Is the file name important? > I’d suggest it's not "important", and if it was, be incorporated into the > location value. Beyond location, I’d suggest it’s beyond the scope of this > draft. > > Scope > I believe we’re all focused on keeping the scope minimal, engaging other > specs where needed, which can add other header values to an envelope. > We’re not trying to make a package manager, rather provide the minimal > required properties to make hash-envelope useful. > Since a complete scenario would involve downloading the content, > confirming the hash matches, and knowing the size/length would mitigate DOS > attacks, I do believe it meets the bar for scope, or the draft could be > argued as incomplete. > > 122 Meeting > I requested time from the chairs to discuss in the COSE meeting on > Wednesday > > Steve > > > -----Original Message----- > From: Henk Birkholz <[email protected]> > Sent: Wednesday, March 5, 2025 2:28 AM > To: Orie Steele <[email protected]>; Carsten Bormann <[email protected] > > > Cc: Steve Lasker <[email protected]>; Ilari Liusvaara < > [email protected]>; cose <[email protected]> > Subject: Re: [COSE] Re: I-D Action: draft-ietf-cose-hash-envelope-02.txt > > Hi Orie, > > in summary what I read is: > > * this is exiting but does not belong here > * adding hash-env-sigs to existing systems > > The question is, how much "convenience information" belongs in an > "un-profiled" cose hash envelope for existing systems, right? > > Pointing to an instance of the pre-image is already an option. > Indicating the intended size of the pre-image seems to be very close, > semantically. > > So the question is about scope creep vs. simplicity of resulting RFC. Yes? > > We added the "length" (are we settled on the name? length? ...) due to > Ilari's feedback. If I want to convey metadata about a pre-image, there is > already RFC9393. In consequence, I am leaning very so slightly to Orie's > point and "keeping it simple". I acknowledge the intended use for that > size... sorry length value, but I am not sure that this is the right place > (aka the right I-D) to address it. > > Are there any other strong proponents for an optional pre-image "length" > header parameter? If not, maybe we can come to an in-room decision at IETF > 122 meeting and not include it. > > > Viele Grüße, > > Henk > > On 05.03.25 03:49, Orie Steele wrote: > > Hi, > > > > I'm hesitant to start considering file transfer in scope for this draft. > > > > The original motivation was to create a simple standard syntax for > > signing hashes that are already used as identifiers, such as sha256 of > > spdx sbom, or container hashes... > > Delivery and integration for these is already a solved problem. > > > > We now seem to be imagining using hash envelope as part of some > > verifiable build system, that uses the optional location, content type, > > and a new file size parameter, to resolve large binaries from small > > signatures and verifiable metadata. > > > > That's exciting. > > > > I'd been imagining adding hash envelope signatures to existing systems, > > not using it to build new artifact repositories or package management > > systems. > > > > At a certain point, it's probably better to sign a corim manifest (which > > as you can see also includes hashes)... And let the manifest carry the > > information necessary to download data. > > > > That's all exciting stuff, but I prefer to not include it in this draft. > > > > Simplicity is what makes successful standards. > > > > I'm not opposed to profiling hash envelope to build a package manager, > > especially one that works well in constrained environments, I would just > > prefer address those requirements in a dedicated document. > > > > Regards, > > > > OS > > > > On Tue, Mar 4, 2025, 10:55 AM Carsten Bormann <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Orie, > > > > > What happens if the resolved file has the correct hash, but > > incorrect file size? > > > > You invoke crypto agility and choose a better hash function :-) > > (I understand Ilari’s argument that being able to limit the file > > size before computing the hash can help mitigate DoS.) > > > > > I wonder if there is some CBOR related filesystem RFC that could > > provide the file size and other relevant metadata. > > > > file-entry = { > > filesystem-item, > > ? size => uint, > > ? file-version => text, > > ? hash => hash-entry, > > * $$file-extension, > > global-attributes, > > } > > > > Not an RFC yet, but pretty advanced already: > > > https://www.ietf.org/archive/id/draft-ietf-rats-corim-07.html#appendix-A-1 > < > https://www.ietf.org/archive/id/draft-ietf-rats-corim-07.html#appendix-A-1 > > > > > > Grüße, Carsten > > > > > > _______________________________________________ > > COSE mailing list -- [email protected] > > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
