Room: Liffey A -
https://datatracker.ietf.org/meeting/121/floor-plan?room=liffey-a
Notetakers: Thomas Fossati, Giri Mandyam
15:00 - 16:00 UTC
15:00 - 15:05 Agenda Bash & Logistics
(5 min) Nancy Cam-Winget, Kathleen Moriarty, Ned Smith
Meeting started. No changes to proposed agenda.
**15:05 - 15:20
Giri
CORIM update.
Github status: pending issues, 29. 10 are text clarificatio, 12 are
verifier algm. improvement.
Security Version Number (SVN) has been carified. Appraisal claim set
definition has been improved. Device ID triples concept has been
clarified.
The CoRIM editors run an open, weekly call. Everyone is invited to
participate. The details are in the repo
https://github.com/ietf-rats-wg/draft-ietf-rats-corim/README.md.
Added triples support for multiple measured "elements" in the same
environment. mkey is the way to disambiguate each measured element.
The change impacts the reference-values and endorsed-values triples.
Internal representation of data needed for verifier processing is being
worked on.
Kathleen: How many people have read the draft?
Yuxuan Song: +1
Yogesh: Please read it and provide feed back.
Giri: Is there a connection between SCITT and CoRIM?
Yogesh: yes, there is a connection.
Giri: is there intention to incorporate work with SCITT?
Yogesh: I'm also author to SCITT work, so we can add including endorser
using CoRIM
Henk: wants to add guidance doc, CoRIM integrates and thus is similar to
SBoMs so reference api can also query and get results thru CoRIM
Yuxuan Song: relation between appraisal claims-set and ECT?
Yogesh: ECT is the building block. ACS is appraisal context which keeps
getting updated as the appraisal progresses.
Dave Thaler asked via chat about the COBOM reference being missing,
which Kathleen relayed to the room, where the content
seems to be in the CORIM spec itself. Henk Birkholz responded saying yes
that is an oversight and verified that the authors
will remove the broken external reference.
15:20 - 15:35 Conceptual Message Wrappers - WGLC
(15 min) Thomas Fossati -
https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/
CMW update.
Recap: Conceptual Msg. Wrappers are wrapper formats for transport of
remote attestation messaging. It covers both JSON and CBOR based data
structures. It reuses existing IETF Media Types.
Recently conclued Hackathon: Leveraged current Veraison implementation
(Veraison is the reference verifier implementation; Linux Foundation
project). An ergonomic abstraction for CMW recursive nature is required
based on findings, and this will inform next draft revision.
Updates since last IETF (120): Editorial clarifications, additional sec
cons, non-native CBOR tag handling, doc restructuing and IANA request
revisions.
Collection-wise security was clarified in sec cons for the scase of CMW
collections corresponding to layered attestation.
Open issue: type system for CMW's should be tightened. Current CMW tag
derivation only requires CBOR tag registration, but could lead to a
conflict with a corresponding registered media type. Proposl is to
remove option to associate CMW tag with pre-registered CBOR tag. Rather,
CBOR tag will be derived from registered media type. The downside is
that legacy implementations may not be supporting this approach.
Preparing for WGLC exit: shepherd has been assigned. New draft to be
published.
Q&A:
LLundblade: Expressed concern that proposed tag registry approach will
not fix all issues. Also does not agree with doc assertion that CMW
collections are superior to EAT submod approach, but Thomas confirmed
the problematic text has been removed.
Deb Cooley: Follow up question on early registration of tags. Thomas
confirmed that it is no longer required.
15:35 - 15:50 Attester Groups for Remote Attestation
(15 min) Jun Zhang -
https://datatracker.ietf.org/doc/draft-labiod-rats-attester-groups/
Already discussed in the interim meeting.
Absorbed feedback from interim and list into the latest release -01.
Is the "attester group" is a concept already modelled in the
architecture?
We propose an extension to the architecture.
Q&A:
Giri: are you planning to add a discussion how an anti-reply mechanism
is plugged into the attester group?
Jun Zhang: yes
Kathleen: I can't see how posture and attester group can be merged
because they use a different architecture. Besides, posture is already
adopted, so the question for the WG is: do we want to adopt a
conflicting architecture?
Jun Zhang: will need to consider this
Kathleen: this is why there needs to be more discussion, within the
group.
Yogesh: have you heard of swarm attestation and how is that different
from your approach?
Jun Zhang: I have seen it but I haven't seen anything in the context of
the RATS WG
Usama: is the same as Intel's EPID; there are privacy concerns
Jun Zhang: our concern is reducing size of evidence, not privacy. If one
in the group is not trustworthy then the whole group is considered
untrustworthy
Thomas Fossati: In your model isn't there already a "lead attester"
which signs the topology? If such is the case, this would not need a
change in the architecture because you could map it to a more abstract
"composite device".
Jun Zhang: If the topology changes for remote attester group, then this
may be difficult to implement. We expect multiple nodes can act as a
lead attester in that case.
Thomas Fossati response: Recommend modeling changing topologies with
changing lead attesters.
Dave Thaler: identifiers in the draft is more of a group nature not
individuals (from my understanding of slide 6), so ts similar to DAA.
This could be an alternate use case to the DAA use case could be a
differentiation to the posture assessment.
Katheen: the posture assessment has already been adopted and is a
different architecture/flow
Dave Thaler: DAA draft has also been adopted, so this could just be
another section in daa draft that enumerates this other use case
(scalability rather than anononymity)
Ned: then proposing that this is an addition to the daa draft vs.
needing a new draft
Henk: we can look at the synergies with the DAA draft. To get a plane
certified, initially all components are literally identical to make
certifacet of such a complex system composition possible in the first
place. That is when the Attester group forms. When "activating" the
plane after certifiaction, all the identical components are "customized"
and during that procdure the Attester Group's evidence production
benefits kick in. I.e., the certification could happen with Attester
capabilities included, which is the "cool new thing". We must be careful
to the use cases as we consider the path forward as this draft addresses
homogeneity
15:50 - 16:00 Handling multiple verifiers in RATS architecture
(10 min) Jun Zhang -
https://datatracker.ietf.org/doc/draft-zhang-rats-multiverifiers/
RFC 9334 only has one verifier, but in practice one may need more than
one verifier.
Resilience is the underlying reason why the verifiers can't be seen as a
single logical verifier.
Thomas Fossati: Can you please explain why resilience is the key to
understand why you need a new conceptual role?
Jun Zhang: At RP side, you can configure the verifier. But RP should be
able to configure the verifiers used.
Thomas: How is this different from a web server farm?
Jun Zhang: RP's can have more freedom to handle time of freshness, how
the attested result is composed, different trust models between verifier
and RP.
Thomas: This kinds of "routing signals" are already possible (picking
which back-end to use)
Jun Zhang: RFC 9334 does not support this currently. It does not provide
guidance on how RP's can assign multiple verifiers.
Thomas: That is relevant to implementation.
Jun Zhang: This gets back to the reliability topic.
Usama: Let's say there are 3 verifiers, one is not available and one is
compromised. The 3rd one is correct, but the 2 available verifiers are
giving conflicting results.
Jun Zhang: In that case, the verifier manager will need to increase the
pool of verifiers.
Ned: This corresponds to the Byzantine Generals' Problem.
Henk: agrees with the byzantine agreement protocl approach analogy
Room: Wicklow Hall 1 -
https://datatracker.ietf.org/meeting/121/floor-plan?room=wicklow-hall-1
Notetakers: Giri Mandyam, Mike Ounsworth
15:30 - 17:00 UTC
15:30 - 15:35 Agenda Bash & Logistics
(5 min) Nancy Cam-Winget, Kathleen Moriarty, Ned Smith
Chairs thanked Nancy Cam-Winget, outgoing co-chair.
Clight change in agenda. mcr presentation will be 2nd
15:35 - 15:50 Evidence Carrying Protocols
(15 min) Michael Richardson - https://datatracker.ietf.org/doc/rfc9334/
Presentation on why RFC 9334 did not provide a protocol or requirements
for a protocol.
Proposal to collect a list of all specs which do define protocols,
particularly those that carry evidence.
What other protocols are carrying Evidence?
What other protocols are carrying Attestation Results?
Things that came out: TPM, TCG, CHARRA, WebAuthn, ACME
Henk: CHARRA
Yogesh: You have made a good question. I think we should help you fill
in the list.
Dave Thaler: Question on the scope of your question: are you looking to
collect things outside the IETF as well?
MCR: Yes. Even if you need 6 NDA's to read the details, we should
include the name in the list.
Dave: Then, referring to the previously discussed conjecture "Every
authentication use case is an attestation use case", the set will likely
be large/unbounded, as you said earlier in the presentation.
Usama: 9334 does define elements of a protocol. For instance, the
attestation nonce is different from the transport challenge data.
MCR: ACK
Ounsworth: Recommend taking this to email. Recommend adding WebAuthn and
ACME to list.
MCR: Invoking Cunningham's Law.
Monty Wiseman: TCG and TPM have Evidence and AR formats. Will contribute
TCG-related protocols to list.
Giri: I would like you to distinguish that not everything with an API
needs to be a protocol.
MCR: Right. Where I wrote "Evidence protocol", maybe change that to
"Evidence thing". I am not restricting to protocols.
Zhang Jun: Sometimes the Evidence and AR are used differently (MCR: of
course). We need to address how to carry nonce.
Peter Liu:
15:50 - 16:05 PKIX Evidence
(15 min) Hannes Tschofenig -
https://datatracker.ietf.org/doc/draft-ietf-rats-pkix-evidence/
Mike Ounsworth presented PKI-based Attestation Evidence.
Initiative came from HSM vendors primarily.
Motivation is to keep with ASN.1 even thought CBOR is being more
widely-adopted.
Acknowledged relationship with ongoing attested CSR effort in LAMPS, but
this effort is focused on DER casting of EAT.
Trying to leverage EAT claims set syntax. Looking into whether a new CMS
profile is required. Group is looking into best approach.
EAT submods CDDL is complex for casting into ASN.1. Particularly
cross-type submods (e.g. CST in JWT) proved to be problematic, but CMW
is the preferred approach.
LLundblade: Complexity acknowledged, but content types may be more
attractive than CMW.
Ounsworth: Please help the authors on the list; this work cannot
progress without a solution.
Henk: CMW allows combination of existing media types.
Giri: Would it help to restrict to only nesting of same data types (e.g.
CWT only)?
Ounsworth: Doesn't matter. It's all DER.
LLundblade: Nesting of different data types will be required.
Question from Ned: Is nesting of different token types too much for the
WG? Does it correspond to a real-wrold use case?
Kathleen: Too much flexibility will confuse developers.
Henk: For ASN.1, just allow nesting. Don't get thrown off by EAT nesting
of different token types.
Ounsworth: This is actually a minor issue for the overall effort.
Hannes: Agree with Laurence. Composite devices will have different data
types.
LLundblade: A content type and binary blob is sufficient for nesting.
A hackathon example was developed by Hannes
Proposal to split document into 2: (a) Encoding of EAT claims into DER
and (b) Key attestation architecture and claims in DER and EAT formats
Another document can be developed for encoding of attestation results
into .509 certs.
Jun Zhang: How does this doc relate to the Attested CSR doc in LAMPS
Ounsworth: CSR is about the evidence container. This doc is concerned
with specific claims. Container vs content.
Jun Zhang: What kind of attestation is this draft concerned with? Only
key attestation?
Ounsworth: Answer not so simple. Nuances such as FIPS compliance.
16:05 - 16:20 Verifiable Service Mesh
(15 min) Ramki Krishnan
Usama: In the image, why do you need three different TLS connections?
Ramki: They are all the same TLS connection, or they indicate multiple
subsequent TLS connections. We have drawn them this way to indicate that
these may be short-lived connections.
Usama: How much time to you expect between these subsequent TLS
connections in steps 2, 3, 5.
Ramki: It's all essentially real-time, but may be up to minutes if there
is load spikes of hundreds connecting at a time.
Giri: The client itself could be Confidential Compute compliant. Yet
there is no flow here for the client to attest before the workload is
moved into a SASE container. Are you considering adding this?
Ramki: This verification is separate and not in scope of this
discussion.
Yogesh Deshpande: Instead of multipfying the number of verifiers to
address scaling. Have you considered having multiple verifiers (within
.. something).
Ramki: You have to be very careful when provisioning the amount of cloud
resources for scaling.
Yogesh: I have some ideas. We can talk offline.
Henk: Some of this problem space seems to be overlap with multi-verifier
and posture-assessment work.
Kathleen: I think there will need to be a lot more discussion on
architecture before go-forward.
Usama: ... continuation of questions about the steps 2, 3, 5, and where
nonces apply, and assumptions about over which period of message
exchange the attestations are considered to be valid. Repeated 3
questions from the Mailing List that were not answered during the
presentation.
Zhang: Suggestion: use the same nonce througout. We can discuss by
email.
16:20 - 16:35 Security considerations of attested TLS
(15 min) Muhammad Usama Sardar
We need to distinguish between protocol nonce and attestation nonce.
Clarified difference between relay attack (where MITM abuses nonce to
present evidence on behalf of an attester) versus replay (evidence
freshness)
Ounsworth: Per-claim freshness and integrity implies no trust in the
attester and measurement collection environment, which is a bit of a
weird position.
Usama: Per-claim integrity and freshness can be met by an attester while
maintaining trust in the attester. We are defining basic requirements of
remote attestation. How these requirements are achieved and what is
trusted in order to achieve these requirements are orthogonal to basic
requirements.
Kathleen / MCR: Usama's work probably warrents a new document that
updates 9334.
Zhang Jun:
Usama: Base security properties/requirements of attestation protocol
should be defined independent of the transport protocol. attestation
nonce is not part of the standard TLS protocol, so it is not a property
of standard TLS.
(Mike Ounsworth injecting directly into the notes: this is not true
because protocols can be extended to explicitly carry an attestation
nonce)
Usama: sure, protocols can be extended, as we do in attested TLS.
Thomas Fossati:
Henk: if you use a nonce then you have certain attack models. If you
don't then you have different ones: RE: replay vs relay attacks. It
depends on the interaction model, which is maybe the right place to
address your concerns.
Usama: Security requirements are orthogonal to any interaction model and
any implementation.
Kathleen: chairs ask Usama to write a draft "extended security
considerations for 9334" that updates 9334.
16:35 - 16:45 RATS Endorsements
(10 min) Dave Thaler -
https://datatracker.ietf.org/doc/draft-ietf-rats-endorsements/
Response to Carl/Kathleen's review: Added a discussion on how trust is
established in endorsements, and secure binding to an endorsement
service (e.g. via a trust anchor). Also moved SecCons from a sub-section
to a top-level section.
Also added layered attestation considerations and apprasial policy
sources to Sec Cons.
Carl comment on endorsement timeliness: added in GH PR a section on
Timeliness
Giri: Do you believe that the AR and/or AR Policy itself will carry
information about the timliness of endorsements?
Dave: Yes.
Dave will merge open PRs and push a new version to Datatracker, maybe
even today.
Doc can go to WGLC on list after merge.
16:35 - 17:00 Open Mic
(15 min)
Giri:
1) Propose that CCA Attestation EAT profile draft be adopted by WG
2) non-normative draft (vs extension draft) that follows up on 9334 that
addresses Usama's concerns. I am willing to work with Usama.
Deb:
Provided update on RFC Ed status. Recommended UCCS and EAT Media Types
follow media type registration process in order to move those docs out
of DISCUSS.
Chair Decisions:
RATS Endorsements draft transitioned to WGLC.