Subject: [Rats] Martin Vigoureux's No Objection on charter-ietf-rats-00-00: (with COMMENT)

From: Martin Vigoureux <[email-masked]>
Date: Thu, 07 Feb 2019 00:35:45 -0800

Martin Vigoureux has entered the following ballot position for
charter-ietf-rats-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-rats/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hello,

I mostly have questions for clarifications. Thank you.

   Relying parties require evidence about the trustworthiness of remote system
   components [RFC4949] they interact with. Remote attestation procedures (RATS)
   enable relying parties to establish a level of confidence in the
   trustworthiness of remote system components by creating and processing
   attestation evidence.
I'm not a native English reader, but this sentence gives me the impression that
the relying parties will create the attestation evidence.
Is that the case? My limited understanding of the topic makes me think that the
remote system will create the attestation and the relying parties will process
it.

   While a relying party may use reference values to assess the
   assertions/claims the procedures for this activity are out of scope for this
   WG.
I can understand why, but I would also see some value in having a document
which would cover this.

About the "proprietary attestation technologies", are these publicly
available/accessible? (similar to Ben's question)

   The architecture may include a system security model for the signing key
   material and involve at least the system component, system component
   provider, and the relying authority.
Does that imply new work or is it just about reusing what may already exist?
But I see Adam had a similar question.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Feb 2019 17:21:00 -0600

> https://datatracker.ietf.org/doc/charter-ietf-rats/

That is a keen observation and correct inference, thank you!
My current local copy has "Remote attestation procedures (RATS)
enable relying parties to establish a level of confidence in the
trustworthiness of remote system components through the creation of
attestation evidence by remote system components and a processing chain
towards the relying party." (further wordsmithing welcome).

> I can understand why, but I would also see some value in having a document

The intent is that this is out of scope for the initial effort but it is
hoped that we can address this eventually.  So I think I should add
"(without rechartering)".

> available/accessible? (similar to Ben's question)

I assume that they would need to have some level of public visibility in
order for the WG to be able to examine them.  I don't know if we need to
explicitly restate that "any technologies adopted by the WG need to be
consistent with the open standards process of BCP 9".

> But I see Adam had a similar question.

My understanding is that the intent is to assume as a prerequisite that
there is key material available and a way for the relying party to verify
its provenance.  This need not be a PKI and could be a
manufacturer-brokered lookup, and I expect that the varied use cases will
end up requiring different stories for key material certification.  We can
talk a bit more in Adam's ballot thread, but I would characterize this as
"not intending to establish a new PKI".

Thanks for the good comments,

Benjamin

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 19 Feb 2019 18:55:20 +0000

> -----Original Message-----
> From: Martin Vigoureux [mailto:[email-masked]]
> Sent: Thursday, February 7, 2019 3:36 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Martin Vigoureux's No Objection on charter-ietf-rats-00-00: (with
> COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 
> I'm not a native English reader, but this sentence gives me the impression
> that the relying parties will create the attestation evidence.
> Is that the case? My limited understanding of the topic makes me think that
> the remote system will create the attestation and the relying parties will
> process it.

You have it right.  The remote systems provide the claims that are used by the relying party to make trust decision.

> I can understand why, but I would also see some value in having a document

You are not alone.  This topic was the source of significant discussion on the RATS list with groups arguing for its need and others seeking simplicity.  The program of work used at IETF 103 listed an additional item, "Specify interoperable protocols to appraise attestation evidence via reference values.", to capture such a protocol.  However, after significant discussion on list, the consensus of the participants during the Jan-16-2019 telcon on WG scoping (https://mailarchive.ietf.org/arch/msg/rats/-rq_gQq2LNTeofG55xH_wPSB1_I) was to reduce the scope the charter to areas of agreement.  This consensus led to the addition of the referenced language above making work on references value out of scope.  If the WG is approved, and with the benefit of the currently defined work, this topic would be revisited.

> available/accessible? (similar to Ben's question)

Yes.  The referenced language was cleaned up in -02 to more cleanly delineate inflight IETF work, inflight community work, concluded IETF work, and existing proprietary tech.  This new text references the starting points of RATS:

--[ snip ]--
The working group will cooperate and coordinate with other IETF WGs such as
TEEP, SUIT, and SACM, and work with organizations in the community, such as the TCG
and the FIDO Alliance, as appropriate. The WG will also evaluate prior work
such as NEA and proprietary attestation technologies like the Android Keystore.
--[ snip ]--

Is that clear enough?

> But I see Adam had a similar question.

New work may be required, but that's not the starting position.  The intent is to reuse as much as possible and define something new only when existing work doesn't meet the requirements.  

Thanks for the feedback!

Roman