Notewell and resources were presented.
Jon Geater agreed to take minutes (when not presenting)
RFC 9596 and RFC 9597 are published. Thanks to everyone who contributed
to getting them that far.
Chairs asked if anyone has reasons not to move current waiting drafts
into request for publication. Hearing none, chairs will press the
buttons after the meeting.
Mike Prorock recommends that pre-hashed and not-pre-hashed should be
dealt with in separate drafts, and asked for comment.
Mike Jones agreed that they are different, and perhaps need a different
algorithm identifier to hint to the compute unit doing the crypto
whether it's prehashed or not.
Sometimes you'll want to do the raw version (for instance small
payloads, constrained devices) but that still needs to be separately
identified.
Mike Prorock expects to have both versions written up and ready for
submission before IETF 122.
Mike Prorock suggests the document is ready for working group last call.
No objections, chairs will make the call after the meeting.
Mike Prorock presented on Sphincs progress.
Appeal to the community (LAMPS?) for implementations, testing, etc to
help gain confidence.
Mike Prorock presented on Falcon. Blocked behind FIPS 206.
Question about test vectors.
Jon Geater presents the current state of COSE and some questions of how
large is the COSE_Sign1 Envelope with large payloads? Detached payloads
could be a solution, but offer additional issues.
Hashed payloads, going back to Mike Prorock's point, there needs to be
an explicit identifier for a payload being a hash or the payload
coincidentally being the same size of a common hash length.
Carsten Bormann: Is this a good time to do the early allocation?
Jon Geater: Yes, this would be a great time. Requesting for a
pre-allocation.
Cedric Fournet: Yes please, currently implementing it so allocation
would be great.
Giridhar Mandyam: Detached hash bundle, is the proper way to go. Do the
attestation specs need to be redone? Does it need to be put in
non-normative text?
Jon Geater: Keep making recommendations and reviewing the work.
Hannes Tschofenig: Precursor work is cited in the document and it would
be very disruptive to conduct rework.
Steve Lasker: vCon is a known structure and format and this would allow
us to identify the content type.
Carsten Bormann: Do we fudge with the algorithm or do we hash the hash?
We are fudging. Be more explicit.
Jon Geater: We have more work to do in the security considerations
section.
Discussion ensued on exactly where hashing happens. Clarified that we
hash the orignal object, then take that output to form our payload along
with its algorithm identifiers. Then it's a completely normal CoseSign1
over the protected header and payload which may or may not include
another hashing step as part of its operation.
Hannes introduced some background history on Contexts in COSE. Basically
a COSE representation of what's in a NIST specification (like SP-800-56A
which covers KDFs) and helps with finding and specifying where you get
parameters from, for example.
Still some confusion remains with nested or complex structures...which
one's the key exchange algorithm vs the signature algorithm?
First version of HPKE was difficult to implement and had difficult
interop challenges, so it has undergone evolution, particularly
flip-flopping on whether to include the COSE_KDF_Context. Other
problems around payload size and out-of-band material were problematic.
Looked to LAMPS for inspiration, particularly RFC 9629.
Seems like it's difficult for everyone. How do we come up with a way of
making sure developers can sanely create messages that can be sent from
one place to another and maintain quality?
Brian injected a modicum of snark. The room enjoyed a moment of levity.
Hannes recommended that since it is impossible to trust the header of
the message you receive (except in extremely special circumstances) we
should embrace a structure that explicitly relies on out-of-band
material and then uses COSE information available to both parties to
allow them to identify and use the out-of-band info.
Requires more review. Mike Jones and Orie Steele both suggest the JOSE
group would be a good place to ask.
Carsten Bormann questioned how is it that we don't have the key info in
the COSE structure? Hannes responds that yes, there is space for key
information but it doesn't take account of nested keys, or algorithm
combinations or so on. Carsten suggests we 'just' need to make a better
key/algorithm field.
Renzo Navas commented that he has successfully used the COSE key
structure for KDFs and it was OK. Lacking things but extensible. Let's
try to improve that.
He followed up with a comment: https://hal.science/hal-01522039 in
section III I use the OSE_key structure to do what I wanted to do, I
need to read the paper again wrote it some time ago
Hannes opens with an announcement:
PLEASE IGNORE THIS PRESENTATION IF YOU:
The document already includes a couple of algorithms. Mike Jones asked
why those two in particular? They were chosen by the authors based on
personal insight and work already done in TLS.
Hannes asks for comments on adoption. Chairs will raise the question
officially after the meeting.
Response to a plaintext recovery attack. This was enabled by
manipulating individual but related fields in the COSE encoding of a key
exchange conversation.
Appeal for volunteers to read the draft before we can call for adoption.
3 volunteers:
Brian made observations about the care that needs to be taken in making
a broad sweeping change to all COSE rather than hardening each
individual algorithm.
Cedric Fournet asks if including the encryption algorithm is sufficient.
Hannes opines that there's a lot of historic confusion around key
exchange and how they've been specified all over the IETF. Maybe we
should sweep all of those and tidy up before focusing on the details of
specific documents.
Laurence Lundblade speaks against wedging another key exchange layer in
saying there are better alternatives. Hannes responds that the
cryptographers who discovered the attack endorse this solution. Laurence
agrees that the proposal does solve the problem, but is wasteful, and
suggested an alternative (which I, the note-taker, missed). Hannes
responds that the suggested alternative doesn't work. Robust discussion
ensued around interoperability and document management concerns.
Mike Jones pointed out that this is only relevant if you want to allow
non-AEAD algorithms (because otherwise the attack doesn't apply) so
solutions can take that narrower scope into account.
Robin introduced the motivations for a new log format, mainly in terms
of security and non-functional properties.
COSE Receipts were a great vehicle for transporting all the info, but
the defined log format lacked the specific properties needed. However it
does establish a registry for new formats, which Robin will present
today.
Robin presented the COSE/CBOR structure that would transport the
efficient inclusion proofs and consistency proofs of MMR in line with
cose-receipts.
Robin presented a visualization of the tree structure that is being
included.
A number of related materials and implementations were presented,
including test vectors and side-by-side implementations to compare with
related technologies like Certificate Transparency.
Jon Geater approached the mic to suggest that MMR and CCF drafts need to
follow the same process: either both profiles of cose receipts or both
individual drafts, but not one of each! Also will make review easier.
Need to see some reviews on-list before adopting.
Reviewers:
Henk introduced background of CCF and confidential attestations.
There's a lot of CCF implementation but it doesn't use COSE yet. Have a
chance to apply COSE and SCITT to this (in particular Microsoft Azure
Confidential Ledger).
Henk presented the CDDL of a CCF inclusion proof.
Henk acknowledged the need for working group work to harmonize MMR and
CCF as consistent profiles of receipts.
Reviewers are required before we call for adoption:
Giri Mandyam asked if COSE would make a problem for CCF which is based
on web transactions. Henk says no, it's not a problem in this case.
Cedric Fourent amplified that there is already accommodation for mixing
COSE and non-COSE in CCF implementations.
Henk explains that this shows the value-add of SCITT and Variable Data
Structure agility in COSE Receipts. This can be added alongside whatever
you have and with whatever long term choice of VDS required.
No requests for AOB. Meeting adjourned at 14:56 local time.