Subject: [Rats] Alissa Cooper's Block on charter-ietf-rats-00-00: (with BLOCK and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Thu, 07 Feb 2019 06:43:06 -0800

Alissa Cooper has entered the following ballot position for
charter-ietf-rats-00-00: Block

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/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Given that the data to be exchanged for remote attestation purposes could be
security-sensitive or could be used to fingerprint a device or identify a user,
I think the charter needs to explicitly state what the WG's goals are for
taking the protection of this data into account.

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

Given that TCG and FIDO Alliance work are both mentioned, I wonder if it is
worth explicitly saying that the WG will coordinate with them as necessary.

I would suggest being explicit about whether the use cases are expected to be
documented in a stand-alone document, and if so whether the WG intends for that
document to be published as an RFC.

"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." --> It's not
immediately obvious to me what "reference values" means in this context. Might
be my ignorance but figured I would note it.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 7 Feb 2019 16:13:45 +0000

Thanks for the feedback.  New proposed text suggested inline.

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Thursday, February 07, 2019 9:43 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Alissa Cooper's Block on charter-ietf-rats-00-00: (with BLOCK and
> 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.)
> 
> 
> 
> Given that the data to be exchanged for remote attestation purposes could
> be security-sensitive or could be used to fingerprint a device or identify a
> user, I think the charter needs to explicitly state what the WG's goals are for

Makes sense.

OLD:

This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to the relying parties.  

NEW:

This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to the relying parties.  Given the security and privacy sensitive nature of these assertions/claims, the WG will specify approaches to protect this exchanged data.  

Makes sense.

OLD:
The working group will cooperate and coordinate with other IETF WG such as TEEP, SUIT and SACM as appropriate.  The WG will also evaluate prior work such as NEA and proprietary attestation technologies.

NEW:
The working group will cooperate and coordinate with other IETF WG such as TEEP, SUIT and SACM; and work in the community such as TCG and FIDO Alliance, as appropriate.  The WG will also evaluate prior work such as NEA and proprietary attestation technologies.

> I would suggest being explicit about whether the use cases are expected to
> be documented in a stand-alone document, and if so whether the WG
> intends for that document to be published as an RFC.

Yes, there is a desire to publish use cases.

OLD:
1. Specify a terminology, architecture and use cases that enable explicit (a
set of verifiable assertion/claims is transported in the attestation) and
implicit (a set of assertions/claims is implied by possession of a secret)
attestation techniques. 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.

NEW:
1. Specify use cases for remote attestation.

2. Specify terminology and architecture that enable attestation techniques.  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.

3. [... renumber the rest as a +1]

> "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." --> It's not immediately obvious to me what "reference values" means
> in this context. Might be my ignorance but figured I would note it.

Does this new text clarify it?

OLD:
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.

NEW:
While a relying party may use reference, known or expected values or thresholds to assess the assertions/claims, the procedures for this activity are out of scope for this WG.

Roman

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 7 Feb 2019 16:31:46 +0000

> From: Roman Danyliw [mailto:[email-masked]]
> Sent: Thursday, February 07, 2019 11:14 AM
> To: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>
> Subject: RE: Alissa Cooper's Block on charter-ietf-rats-00-00: (with BLOCK and
> COMMENT)
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> >
> > Given that the data to be exchanged for remote attestation purposes
> > could be security-sensitive or could be used to fingerprint a device
> > or identify a user, I think the charter needs to explicitly state what
> > the WG's goals are for taking the protection of this data into account.
> 
> Makes sense.
> 
> OLD:
> 
> This WG will standardize formats for describing assertions/claims about
> system components and associated evidence; and procedures and protocols
> to convey these assertions/claims to the relying parties.
> 
> NEW:
> 
> This WG will standardize formats for describing assertions/claims about
> system components and associated evidence; and procedures and protocols
> to convey these assertions/claims to the relying parties.  Given the security
> and privacy sensitive nature of these assertions/claims, the WG will specify
> approaches to protect this exchanged data.
> 
> 
> > Given that TCG and FIDO Alliance work are both mentioned, I wonder if
> > it is worth explicitly saying that the WG will coordinate with them as
> necessary.
> 
> Makes sense.
> 
> OLD:
> The working group will cooperate and coordinate with other IETF WG such as
> TEEP, SUIT and SACM as appropriate.  The WG will also evaluate prior work
> such as NEA and proprietary attestation technologies.
> 
> NEW:
> The working group will cooperate and coordinate with other IETF WG such as
> TEEP, SUIT and SACM; and work in the community such as TCG and FIDO
> Alliance, as appropriate.  The WG will also evaluate prior work such as NEA
> and proprietary attestation technologies.

More refined language ...

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

> > I would suggest being explicit about whether the use cases are
> > expected to be documented in a stand-alone document, and if so whether
> > the WG intends for that document to be published as an RFC.
> 
> 1. Specify a terminology, architecture and use cases that enable explicit (a set
> of verifiable assertion/claims is transported in the attestation) and implicit (a
> set of assertions/claims is implied by possession of a secret) attestation
> techniques. The architecture may include a system security model for the
> signing key material and involve at least the system component, system
> 2. Specify terminology and architecture that enable attestation techniques.
> 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.
> 
> > assertions/claims the procedures for this activity are out of scope
> > for this WG." --> It's not immediately obvious to me what "reference
> > values" means in this context. Might be my ignorance but figured I would
> note it.
> 
> While a relying party may use reference values to assess the
> WG.
> While a relying party may use reference, known or expected values or
> thresholds to assess the assertions/claims, the procedures for this activity
> are out of scope for this WG.
> 
> Roman

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 7 Feb 2019 11:43:47 -0500

Thanks, all looks good except I have one question below.

> On Feb 7, 2019, at 11:13 AM, Roman Danyliw <[email-masked]> wrote:
> 

Is there a particular reasoning for publishing these in the archival series? (See <https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>.)

Thanks,
Alissa

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 7 Feb 2019 17:30:32 +0000

> Sent: Thursday, February 07, 2019 11:44 AM
> To: Roman Danyliw <[email-masked]>
> Cc: IESG <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Alissa Cooper's Block on charter-ietf-rats-00-00: (with BLOCK and
> COMMENT)
> 
> Is there a particular reasoning for publishing these in the archival series? (See
> <https://www.ietf.org/blog/support-documents-ietf-working-
> groups/?primary_topic=7&>.)

As I recollect, the consensus was around having a use case document, but there was limited discussion on how it should be published.  Perhaps this can be left to the WG and codified as:

OLD (preamble to Program of Work):
The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows.

NEW:

The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are described below.  The WG may chose not to formally publish all of the support documents as RFCs.
 
Roman

> 2. Specify terminology and architecture that enable attestation

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 7 Feb 2019 12:39:19 -0600

Below...

> On Feb 7, 2019, at 10:31 AM, Roman Danyliw <[email-masked]> wrote:
> 
>> 

“Android Keystore” is an implementation not an organization. Maybe this?

LL-NEW:
The working group will cooperate and coordinate with other IETF WGs such as TEEP, SUIT and SACM; 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.

LL

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 7 Feb 2019 19:24:37 +0000

> From: Laurence Lundblade [mailto:[email-masked]]
> Sent: Thursday, February 07, 2019 1:39 PM
> Cc: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [Rats] Alissa Cooper's Block on charter-ietf-rats-00-00: (with
> BLOCK and COMMENT)
> 
> Below...
> 
> >>> Given that TCG and FIDO Alliance work are both mentioned, I wonder
> >>> if it is worth explicitly saying that the WG will coordinate with
> >>> them as
> >> necessary.
> >>
> >> Makes sense.
> >>
> >> OLD:
> >> The working group will cooperate and coordinate with other IETF WG
> >> such as TEEP, SUIT and SACM as appropriate.  The WG will also
> >> evaluate prior work such as NEA and proprietary attestation technologies.
> >>
> >> NEW:
> >> The working group will cooperate and coordinate with other IETF WG
> >> such as TEEP, SUIT and SACM; and work in the community such as TCG
> >> and FIDO Alliance, as appropriate.  The WG will also evaluate prior
> >> work such as NEA and proprietary attestation technologies.
> >
> > The working group will cooperate and coordinate with other IETF WGs such
> as TEEP, SUIT and SACM; work with organizations in the community, such as
> TCG, Android Keystore and FIDO Alliance, as appropriate.  The WG will also
> evaluate prior work such as NEA and proprietary attestation technologies.
> 
> The working group will cooperate and coordinate with other IETF WGs such
> as TEEP, SUIT and SACM; 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.

Concur.  This is better.

Roman

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Feb 2019 16:23:32 -0500

Alissa Cooper <[email-masked]> wrote:
    > Is there a particular reasoning for publishing these in the archival
    > series?

Good question.
I would like us to work on, and do a WG Consensus call on a use-case document.
I think that it could then be brought in as an appendix to another document,
or just left as an internet-draft.

But, I think we need to have a live, working use-case document in order
to be able to avoid the blind-people-and-elephant problem.

(And I'm already working on a candidate document)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

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

> to be able to avoid the blind-people-and-elephant problem.

Of course!

The question comes up largely because there have been several recent cases
where a use-cases document is sent to the IESG and the IESG is
uncomfortable publishing the document in the RFC series, owing to an
unclear quantity of archival value.  (To date, they have all been
published.)  In some cases, the publication of the use-cases document has
been an explicit item in the charter, and I think the IESG is looking to
make a determination at charter time whether future use-cases documents are
expected to have archival value.

So this could be something like:

OLD:

NEW:
1. Specify use cases for remote attestation (to document and achieve WG
consensus but not expected to be published as an RFC).

I will put this in my local working copy, but of course it can change back
or change in other ways throughout the external review process.

> (And I'm already working on a candidate document)

Excellent!

Thanks,

Benjamin