COSE IETF 120

Connection details

• Date and time: Jul 23, 2024 - 9:30-11:30
• Meeting materials:
  https://datatracker.ietf.org/meeting/120/session/cose
• Meeting URL:
  https://meetings.conf.meetecho.com/ietf120/?session=33034
• Recording URL: https://www.youtube.com/watch?v=ktnnj-nTqkc

Action Items

• Chairs: Merkel trees WGLC? --> waiting for Robin's comments to be
  addressed and Orie will let us know.
• Chairs: tsa-tst-header-parameter WGLC - to be started
• Chairs: cose-hash-envelope call for adoption

Minutes

• Jabber scribe: NA (IP monitors)
• Minutes taken by: MCR, Justin Richer?, CA

Opening Remarks - The Chairs [9:30-9:40]

new RFCs: 9596 (typ header), CWT claims (9597)
submitted: cose-key-thumbprint

draft-ietf-cose-hpke - Hannes Tschofenig [9:40-9:55]

HT presenting on behalf of authors

HT: -09 corrected submit-from-wrong-branch troubles
HT (p2): on HPKE change, will be illustrated in next slide. Paul (?)
reviewed security properties.
HT (p3): We still need examples on other fields this may include
(currently only showing algorithm). Hex values in the example are not
correct yet.
HT (p4): My impression, hopefully also Lauren's and Orie's, is we are
approaching finalization.

Sophie Schmieg (SS): You cannot actually protect the algorithm field
with the algorithm itself, the algorithm MUST be determined by the
public key. You have to have external confirmation of the algorithm.
Otherwise, an attacker can say the algorithm is "none" or one which the
attacker can break. You can authenticate it, but that doesn't do
anything. The public key's algorithm ID needs to bind the entire
ciphersuite, if you want to be able to prove security. You can put the
algorithm of the DEK into the KEM, but really putting it in the public
key is probably the better choice. And if you want to do more than one
thing, just make two keys
HT (p3): We'd include party-U/party-V identifiers, ???.
SS: That's a good thing to add. The algorithm must not be authenticated
through that. Ideally, it wouldn't even be there. Should say "You MUST
NOT rely on that header", just "check to be the same as you expect".
HT: Argued with Jim in COSE to not carry this around; lost that
argument.
OS: You're correct. Algorithm is marked optional. Reason for developing
them with COSE and JOSE together is to keep the keys consistent ("key
restriction").

(more on this in the chat)

draft-ietf-cose-dilithium & draft-ietf-cose-sphincs-plus - Mike Prorock [9:55-10:10]

MP presenting.

(p1) on dilithium
MP(p2): Slimmed down now that we can point to NIST specs.

MJ: Who has read this?
(not many)
MJ: Who volunteers to review?
Hannes Tschofenig, Roy Williams
MJ: Who has implemented that draft?
Mike Prorock, Orie
MJ: Have interoperated?
not yet.

Quynh Dang: Are we doing signature ore prehashed?
MP: ???; need comments from the WG.

OS: None of the tests/examples are prehashed. Can still change though.
As we start testing, we'll want to test on the same parameter set. Would
be great to have implementations section.

MJ: When WGLC?
Quynh Dang: Be patient and wait for FIPS to be published.
(+1 on chat from Mike Ounsworth)

(p3) on sphics-plus document

MJ: Who is willing to review?
Roy Williams, Hannes Tschofenig!

(p4) on falcon

MP: Happy to do the work, but is anyone interested in / going to use it?

RW: Hearsay on the hallway is that it is needed for embedded with little
memory

QD: NIST expects to have a draft of Falcon later this year.

draft-ietf-cose-cbor-encoded-cert - John Mattsson or Göran Selander [10:10-10:20]

JPM presenting.

JPM(p2): got comments, not as close to publication as thought, but
approaching.
JPM(p2..3): (see slides for updates)
JPM(p6): pending issues
JPM(p7): implementation report. Would like to see more example
certificates around things we don't know use of (prefer not specifying
things we don't know is working)

MJ: As chair, would prefer issues and chat comments to be resolved
before WGLC. Authors, please tell chairs when you think it's ready.

draft-ietf-cose-merkle-tree-proofs ("COSE Receipts") - Orie Steele [10:20-10:30]

OS presenting.

OS(p1): Hoping this is one of the last presentations on this topic
OS(p2): Background: VDS. Document describes how to put those proof types
into COSE/CBOR encoding.
OS(p3,p4): Example; decoded on p4. 395 syas it's a VDS, 1 says it's this
kind of binary merkle tree. Unprotected 396 is map in unprotected header
because: As looked into VDS structures, this can cover future possible
proof types. -1 is associated to 1 in 395. For each VDS, 1 identifies
the data structure, and -1 is a proof type this VDS can support. A new
VDS for Merkel Squared key transparency would get 2 or 3, and we could
have inclusion proofs, but also prefix tree proofs(?). ??? check the
Merkle proof first, compute the root, check the signature -- thus people
don't accidentally forget the check.

OS(p5): (largely skipped)

OS(p6): Why proofs in unprotected header? Authentication processes for
them is separate from digital signature verification. It's also easy to
add them later. Can always be verified.

OS(p7): (largely skipped)

OS(p8): Rationale: Originally SCITT. Seemed like a general security
feature, thus went to COSE.
OS: In hackathon, looked at incident response, and how binary mgmt could
be part of responding. When recovering servers by plugging in USB
sticks, it's good to have the recovery software authorized. Check that
the binary is in an append-only log and signed.

OS(p9): Early allocs requested to have numbers that can be used in
implementations. (Robin: Robin Bryce(?))

OS(p10): Struggled to get reviews. Asking for WGLC.

MJ: Who read?
MP, JG, ?
FL: Regarding unprotected headers. Makes sense. But what are purposes of
signature in that case? Makes sense for signed tree head, but...
OS: p4. Here, inclusion proof is in unprotected header. Receipt shown is
a signed tree head. Merkle part is in unprotected part.
FL: So signed receipt is two pieces in one message?
OS: Yes.
OS: Also, p3, there is one value and multiple receipts, eg. independent
agencies. Unprotected header is mutable, other receipts can be added
over time. Eg. add more 394 items as requested.
FL: So item is...?
OS: Think about filling that detached payload with some image you try to
secure. Payload is some domain specific binary, but inside receipts,
payload is signed tree head.

MJ: Who has implemented it?
OS, ??? (3.5 in total)
MJ: Tested?
OS: Back to SHA256 binary merkle tree. Done cross-testing with Trillian
to check with Go ecosystem.
MJ: What open issues remain?
OS: See follow-up steps. Robin Bryce's comments.

MJ: Tell me when you think it's addressed, then WGLC.

draft-ietf-cose-tsa-tst-header-parameter - Carsten Bormann [10:30-10:40]

CB presenting for Henk who is in a conflict meeting.

CB(p2): Like previous presentaiton, something countersignature-ish in
unprotected (or protected) header. Infrastructure is out there.
CB(p3): Two modes, this is the first mode. Time stamp becomes part of
the information that is signed. Timestamp goes into protected header,
and can not be meddled with.
CB(p4): Other mode is to Sign1, and independently (maybe even later) ask
TSA to timestamp that signed structure. Can only go into unprotected,
just like Recepts of last presentation. So far, boring no-brainer.
CB: It's actively being used in RATS, so good thing to do this quickly.
WGLC?

MP: Also using this in other external use cases. Ready for WGLC. Can be
implemented cleanly.

MJ: Are there impls?
MP raised hand.

MJ: Hearing no objections, we will start WGLC on this draft.

draft-steele-cose-hash-envelope - Steve Lasker [10:40-10:50]

SL presenting.

SL(..p9): Use case and mechanism (?)
SL(p10): But storage service may not be accessible. I don't want to
bring the binary on to the machine to decide whether I want the binary
("trojan horse case").
SL(p11): What is the payload?
SL(p14): Looking at hash payload case. Now there is something to
verify before fetching 15TB of data. Means that for hashing we need
pre-image content type.
SL(p15): "where is it stored" is not hardened.

Justin Richard: Obvious issue with detached hash is that you still have
to validate the hash, otherwise you blindly accept everything. Seen
skipping that a lot. Can we do anything more than stern warnings to not
skip the hash check?
SL: None of this solves laziness.
JR: Particular issue is more subtle: Here you put in work to check the
sig, convinced yourself you checked it, and then missed it.

RW: Makes sense for here, but end user has to validate content.

MCR: What I was hearing from that question was: Maybe it'd be good to
have a hash over the first 100k, such that when you fetch the 6TB, you
see the direction. Not sure if good idea.
SL: Question is: Is this content from someone I trust? ???

LL: This solution is close to solution for another problem I've run
into. If you want to sign something big with multiple algorithms, can't
do that easily.

MP: Big +1 to LL. One option worth considering is forcing a strict mode,
where hash is in detached payload (you have to calculate the hash to
verify the signature). There might be cases wher that's possible.
SL: Would call this "attached hash scenario". But doesn't help with
trojan horse case.

OS: MCR reminded me that Sign0 exists. Most of the time we look at
Sign1, but Sign0 might solve LL's case.
?: Doesn't solve the case.
LL: Sign0 is used. Dealt with hybrid PQ scenario, Sign0 didn't help with
it. 2-3 year old item on list.

MJ: Show of hands. "Are you in favor of working group adoption of?"
Result:

• yes: 22
• no: 0
• no opinion: 9

MJ: Room is in favor of adoption. Will follow up on list.

draft-tschofenig-cose-cek-hkdf-sha256 - Hannes Tschofenig [10:50-11:00]

HT presenting.

HT(p2): An attack, see LAMPS. Not totally unrealistic, affects integrity
and confidentiality. LAMPS fix (include algorithm identifier in another
key derivation step) is past WGLC there. This document applies the same
line of thinking to COSE.
HT: Short document, but important to address this before it becomes an
issue.
HT: Might also apply to JOSE, should apply the same mechanism there.
HT(p3): Asking to process this as quickly as possible through WG.

SS: Alternative would be to have the algorithm in the ? info, saying
"this algorithm can only be used with this encryption"...???
HT: In HPKE we could include that mechanism, and in some sense we did,
but there are other key distributionmechansims we don't want to alter.
Should we incorporate the technique into HPKE or ...?

LL: Some solutions shown in diagram on mailing list (by ... kenta
kyama?). There is an alternative solution to put algorithm identifier
into the authenticated data of COSE recipient (as HT presented as well).
I prefer putting in the algorithm ID, it's simpler than adding another
layer of processing.
HT: Not sure. HPKE solution is easy for us b/c we design mechansim right
now. For this approach to workin all the other key distribution
mechansims, we have to touch all of them. Could be tricky. There is AES
key wrap, there is ESDH, SSDH, we'd have to work through all of them.
Thus prefer to be with CMS work, even if we decide for HPKE or future
mechanisms to have something else.
LL: Yes, we'd have to look at all of them.

OS: Like the solution b/c it is aligned. On public key restriction
comment. In COSE/JOSE there has never been a way to restrict a public
key to a content encryption algorithm, ever.
HT: Distringuish between layers. ???
OS: Keeps coming up over and over on the lists. ???

OS: There is draft fully-specified-algorithms presented in JOSE.
HT: prefers that we actually use new algorithm numbers rather than
parameters (which was discussed in JOSE)

Mike Ounsworth: What are backward compatibility concerns?
HT: New algorithm IDs.
SS: must be restricted in the public key, but maybe can work with a new
algorithm ID, if it's fixed to one key derivation. The HPKE already does
this.
HT: in the one layer situation, it works easily, but in the two layer
situation it is more complex.
SS: would not call that HPKE.

LL: it gets entertwined with COSE layering. This solution hops around
the layers.
HT: Fair enough.

HT: So we can't go to WGLC yet ;-)

MJ: Willing to read and review?
volunteers to read: OS, LL, SS, HB(?)

draft-reddy-cose-jose-pqc-hybrid-hpke - Hannes Tschofenig [11:00-11:20]

HT presenting.

HT: (first slides overlap with JOSE presentation, skipping a bit)
HT(p2): Talking about middle item.
HT(p6): Proposed registry.

OS: On p6. JOSE and COSE have moved on from HPKE mode in algorithm, this
says "base" here but could also be PSK -- if we do HPKE hybrid in COSE
(and of course we do one in JOSE), we'd need to align around that. (And
says kyber instead of ...)
HT: Copied from CFRG spec. Agree. Will forward.

MJ: Who has reviewed?
Quynh Dang (just now, it's short)
MJ: Please write to the list.
Quynh Dang: Good proposal, support adoption.

OS: Maybe better question: Who is going to deploy this code point?
HT: Answer may not be so easy, companies haven't made up their minds.
?: Going straight PQ.
SS: We will use it if using COSE, but not sure if will use COSE.

MJ: Want to have OS's question on-list. Work is well defined, but need
to understand applicability. Going to ask that on list.

Justin Richard: Generally, keep in mind induced demand. Some
implementers won't touch it until point is allocated. Hard to predict.
OS(chat): +1 on that.
Brian Campbell(chat): induced demand cuts both ways

AOB [11:20-11:30]

---