RATS agenda for Wednesday 29, 2020
-------------------------------------
Chairs: Nancy Cam-Winget, Kathleen Moriarty, Ned Smith
Notetakers: Ned Smith, Eric Voit, Thomas Fossati
Jabber/Chat: Nancy Cam-Winget

* Agenda bash (5min)

No second HUM test.


* Architecture -  Henk Birkholz(15 minutes)
	https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

     There is a large list of contributors that attend architecture team meetings. The list of participants has been updated to include regular participants.
     There are about 14 outstanding issues, but the list is getting smaller. Only a few big items remainging. Most are smaller details related to wording and so forth.
     A new Trust Model section was developed that members of the group are encouraged to read and comment on.
     Two larger topics still remaining:
      (1) Endorsement and Endorser role definition still seems too abstract for many. There is also the possibility that a next phase of the RATS charter could include additional details related to Endorsers and Endorsements.
      (1b) Per Laurence, Key Provisioning is something which may need to be covered as an adjunct to Endorsement interactions (there might be a loophole in the charter that allows that).
Current topics also includes time-keeping based on nonces. Hannes asks the question "what about collection?" There is a new pull request and lots of comments.
      (2) The hardware capabilities limit what elements of time/freshness might be collected or be asserted, as well as the asserted levels of trustworthiness.  Therefore one solution for understanding the time of evidence generation is not viable.
    Looking forward to WGLC in the near future.
    Dave Thaler asked a question about how timestamps and nonces might interact.
    (Dave Thaler) There are constrained devices that don't use a RT clock and you can still be successfully implement protocols for time synchronization. There are multiple ways to accomplish freshness without the architecture dictating a particular approach.
    (Henk) The question remains, "are the examples sufficient or do we need more?"
    (Dave Thaler) There are 4 examples now that form a classic 2X2 matrix. This should be sufficient for demonstration purposes. We shouldn't try to enumerate all possible way.
    (Henk) We're closing this section on freshness soon, so please provide feedback if any remaining cooncerns exist.
    (Dave) TUDA isn't on the agenda for IETF 108, but there is a discussion related to timing in the TUDA document that is referenced from the interactions draft (yesterday's meeting). Dave believes it doesn't make sense for drafts to reference other documents that are not adopted drafts.
    (Nancy) There was an IPR issued against the architecture by Huawei. It isn't clear if the IPR relates to the entire draft or just a part of it.
    (Wei) The IPR is about the composite device section, rather than the document as a whole.
    (Nancy) Can you please work the issue so that is it clarified in the IPR record.

* EAT: Attestation Keys taxonomy - Laurence Lundblade (20min)
	https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
(Laurence Lundblade) Prested slides showing Primary Trust Flow. Diagrams shows who trusts who, how and why. Solid arrows are a more direct trust. Dotted arrows are indirect trust. Verifiers have to trust manufacturer(s) because that is where they obtain Endorsements. Relying Party is "told" by the Verifier whether or not they trust the manufacturers. This is a transitive trust condition.
There is a secondary trust flow that has more to do with privacy and PII.
If the trust flow doesn't work then attestation doesn't work.
(Nancy) When you say "manufacturer" it doesn't have to be only a manufacturer, right?
(Laurence) The architecture uses "Endorser" but Laurence feels this term is unclear still. It isn't a term used in IoT community.
(Rich Saltz) suggests the term "provider"
(Laurence) Shows a diagram illustrating Endorsement materials such as known-good-values, signing keys and verification keys.
Attester must have a secret (key) or something that allows it to prove that it is who it says it is (otherwise known as authentication).
(Dave Thaler) Does "signing keys" refers to private keys that are used to sign Evidence? If so, it may not always be the case that a manufacturer provisions keys. Private keys may originate within the Attester (Laurence agrees).
(Laurence) The point of attestation is there has to be keying material.
Laurence shows a slide about a taxonomy of Verifier and Manufactuerer (Endorser) use of keys. Low cost devices cannot afford to maintain the asymmetric key material, which motivates the use of symmetric keys.
An axis of the taxonomy involves two aspects:
(1) Infrequent interactions
(2) Per-verification (frequent interactions)
Laurence displays a 2X3 matrix showing behavior specific to public keys, symmetric keys and verification services.
(Dave Thaler - from chat window) Attesters can be layered or composite in which case there are multiple such entities in general
Note: the aforementioned clarification is top right of this slide04
Nothing in this slide is really specific to RATS right? The same slide could be used for any use of keys between two entities (given that "manufacturer" is already an ambiguous term).
(Laurence) The point of symmetric key attestation is cost. Constrained devices use symmetric keys and therefore symmetric key considerations should be part of RATS efforts.
(Dave Thaler) Since 'manufacturer' could mean lots of things the slide doesn't have to be specific to RATS. This could be part of a general security area document that can be referenced by multiple working groups.
(Russ Housley) If we were to build such a document, there are security considerations that need to be addressed. The taxonomy is great.
(Nancy) These slides could be presented in other forums as well.
(Laurence) Presents one more slide in the interest of time that drills down on verification key taxonomy.
Laurence solicits input on this topic.
(Nancy) Suggests a side meeting might be appropriate for next steps.


* Trusted Path Routing – Eric Voit (10min)
	https://datatracker.ietf.org/doc/draft-voit-rats-trustworthy-path-routing/

(Eric Voit) Expands on the RATS interim presented topic on trusted path routing.
The objective of trusted path routing was presented. Followed by a document roadmap relating several other drafts.
This I-D includes trustworthiness 'levels' that defines a range of integrity levels having to do with hardware, unique identity, boot integrity, filesystem integrity. Question to the group "Do we want to work in definition of level in RATS?"
(Kathleen) Definitions could be done by another "entity" or group, similar to what is done with policies in PKI.
(Eric) There is a lot of potential for follow on work.
(Eric) An example related to boot integrity was presented. These results are given to the router for inclusion in a routing fabric that implements attestation protocol that is topology based.
Next steps:
(1) Does the WG want to standardize attestation result formats?
(2) Definition of EAP payload?
(3) Is there interest in adoption?
Questions?
(Russ) When you talk about routing protocols, what is the potential support for routing protocols?
(Eric) We can support both IGP and BGP.
(Dave Thaler) I don't know if I understand the trustworthiness vectors, but in TPR then the granularity is in terms of the 'trust layers' that might make sense for TPR but outside of this context, it might be difficult due to variability and heterogenaity concerns.
(Eric) This is a legitimate concern.   The specific claims at a high level might look the same.  In specifics we don't know if they are generalizable.  (e.g., multiple line cards.)
(Nancy) You don't see this draft adopted in RATS?
(Eric) It could be adopted here if it makes sense, I don't know where else that here for routers based on the dependent drafts (e.g., charra)
(Dave) The TPR draft belongs in RATS but doesn't feel strongly about it.
(Nancy) We're 8 min over time. Solicits feedback for interest for adoption.

* SUIT/TEEP Evidence and attestation claims – Henk Birkholz  (10min)
	https://datatracker.ietf.org/doc/draft-birkholz-rats-suit-claims/

(Henk) "Trustworthiness Vectors" term was taken from Eric's draft (Trustworthy Path Routing) with the goal of applying it to TEEP interactions
The consideration that RATS Attester might process a SUIT manifest. SUIT manifests can be used to process remediation procedures.
Trustworthiness levels apply to system properties claims. EAT claims are somewhat specializations or generalizations of SUIT claims. Maybe there should be a mapping exercise performed?
"Trustworthiness Vectors" conceptually simplifies the set of properties that are evaluated / appraised reducing the load on Verifiers.
(Laurence) The reason Verifiers and Relying Parties are distinct is because they perform different roles.
(Brendan Moran) Verifiers can't be fully eliminated (RP can understand claims about system properties itself, but it'd need a verifier to interpret more complex semantics - e.g., coming from SUIT command evaluations) but there seems to be ways that SUIT can simplify things.
(Henk) There are other domains outside of routing that make sense for defining 'trust levels'
(Dave Thaler) In the context of SUIT, "trust" may be the wrong term. Some factors aren't specific to trustworthiness.
(Henk) Only 10 min remaining, but there are aspects that are related to trustworthiness state transitions. Updates are a remediation procedure, but remediation relates to trust.
(Nancy) Called a close to this presentation.

* Unprotected CWT Claims  – Henk Birkholz (10min)
	https://datatracker.ietf.org/doc/draft-birkholz-rats-uccs/
UCCS was recapped by Henk
If a signature over Claims is omitted there needs to be a way to protect the Claims equivalently. In a RATS scope there needs to be a context for how UCCS Claims are protected. This may involve defining the characteristics of the Secure Channel (presumably this is the replacement for an ommitted signature).
There is ongoing discussion on UCCS - looking for input generally from the working group.
(Laurence) Security considerations for UCCS in the RATS context should be included in the RATS security considerations.
(Henk) we pulled the security considerations in the UCCS draft as we want to have an understanding of how to frame this work.
(Laurence) UCCS is used in multiple other places, each needs to have context sensitive security considerations. This can snowball.
(Henk) what would happen if we don't include that, that'd be a disaster.
(Kathleen) Who have read the draft? (5 people)
(Kathleen) Others willing to read the draft? (2 people: Russ, Jessica, Kathleen (but chairs don't count))
(Kathleen) Are we ready for WG adoption? Comment in chat if you think it's ready. (all yes)
(Kathleen) Will take steps to recommend for adoption.


* RESTful attested Resources – Thomas Fossati (15min)
	https://datatracker.ietf.org/doc/draft-shaw-rats-rear/

(Thomas) Goal - Present the main ideas in I-D useful to those interested in building a RATS toolbox.
Use case:
Dam - Water level sensor, Spillway sensor, Spillway gate
    Verifier appraises attestation from the sensors.
Attested Resource - contains a resource representation, Evidence about the hosting platform security state and Freshness indicator.
Interaction Model - A compund data format needed to pull together resource state, attestation data and freshness
RESTful Attested Resources - A 'basic' RESTful interface is used to access attested resources. Uses CoAP and HTTP transports. Optional discovery based on CoRD(?)
Implementation Model - Diagram showing REST Clieent<-->REST Front-end<-->TEE-back-end
Mixing Function - Defines the fundamental security guarantee. Prevents attackers from spicing malicious assertions. Mix(n, r, t) = H($n || $r || $t) --> E.nonce
(Dave Thaler) Why the nonce rather than a separate claim?
(Thomas) This needs more discussion. A separate claim might be reasonable.
(Nancy) Notes that a separate claim might be better.
Attester Interface - diagram showing a challenge - response protocol.
Compositions Examples - diagram showing the background-check model with nonce and using the Mixing Function.
An example of the REST messages was displayed.
The passport model with timestamp was discussed briefly and REST messages displayed.
Discovery example using REST messages was displayed.
Questions:
(1) Is there interest in this?
(2) Should we go forward?
(Nancy) Please take to the mail list

* Milestones – Chairs (15min)

(Nancy) Milestones need to be updated.
Given there are more drafts lets first update the currently recognized drafts then we can look at additional drafts
Adopted Drafts:
EAT, Arch, and Charra
Are we ready for WGLC next month for Charra?
(Henk) Yes we can do that but will be ambitious
(Nancy) Will we be ready for publication in Dec?
(Henk) Make it september (for WGLC)
(Nancy) Target March for publication then? (Yes)
Interaction Models - Call for adoption needed.
Token Bind - to be removed.
EAT - WGLC is needed before it can be submitted for publication.
(Nancy) Is it ready? (for WGLC)
(Laurence) It has a way to go still. (several topics mentioned that needs work)
(Nancy) We need to make progress. Should we target WGLC in Dec?
(Laurence) Seems reasonable.
(Nancy) Targeting IESG submission in 6 months
(Nancy) We haven't mentioned TUDA recently, what is the status?
(Henk) Interaction model should go first because other I-Ds depend on it.
(Nancy) Can't to a call for adoption since it hasn't been presented recently.
(Dave) One can argue that TUDA is a type of interaction model. Remove the TUDA draft and adopt it as yet another interaction model. Proposing to merge into interaction models.
(Henk) That would be too disruptive at this point.
(Nancy) We need a WGLC for architecture draft. Are there remaining issues that prevents WGLC?
(Henk) End of Sep should be the new focus.
(Nancy) We're not opposed to doing multiple WGLC if that helps shake out the issues.
(Nancy) Targeting March for IESG submission.
(Nancy) RIV I-D is already adopted. When will WGLC be appropriate?
(Guy) End of August.
(Nancy) Haven't seen much by way of comments on the list.
(Kathleen) Time check
(Guy) Assume 'yes' unless other issues exist
(Nancy) Post to mail list intent for adoption.
(Nancy) We'd like to hold 2 interim meeting between now and sept. We'll use doodle poll to find a date.

Meeting closed at 12:52 UTC