Subject: [Rats] disposition of remaining pull requests to architecture document

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Sep 2020 11:45:36 -0400

NO DESIGN TEAM MEETING September 15, due to conflicts (ADD virtual interim,
other things).   Next meeting is September 22.

Pull request #130 -- https://github.com/ietf-rats-wg/architecture/pull/130
  The DT felt that the changes focused too much on PII, and removed many
  other aspects of privacy from the text.  We couldn't come up with a
  word smithing way to fix this, so we suggest reviewing the suggestions
  and maybe starting over.

Pull request #94 -- https://github.com/ietf-rats-wg/architecture/pull/94
  Many people on the DT preferred the old text.
  It's been three months without progress or revision.
  We did not understand the goals of these changes, the defects in the
  existing text, so we couldn't find a different phraseing.
  "wontfix"

Pull request #141 -- https://github.com/ietf-rats-wg/architecture/pull/141
  After some arguments over trailing periods.... we recognized that the goal
  of this effort was to find places to make reference to the Reference Values
  (but also cf: https://www.gocomics.com/bloom-county/2015/10/01 )

  DThaler will lead a PR that makes Reference Values more prominent.
  I edited the digram to form:
    https://github.com/ietf-rats-wg/architecture/pull/147/files
  I see it needs a bit more care.  The new term "reference value provider"
  was disliked by all, but it was 2 minutes to the end of the meeting.

Dear WG chairs, WGLC soon?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Sep 2020 10:32:53 -0700

> On Sep 8, 2020, at 8:45 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

I wrote this to help with Kathleen’s comments, but have no strong motivation for it. I will perhaps update it after I get through some other stuff. Don’t hold your breath.

>  existing text, so we couldn't find a different phraseing.

I will probably make another attempt at a PR here, probably different from this one.

>  was disliked by all, but it was 2 minutes to the end of the meeting.

Yes, the reference values was the main motivation in my change. Glad you settled the periods issue without me. :-)

> Dear WG chairs, WGLC soon?

I have two open issues against section 7 that I think are important. I generally think section 7 needs a fair bit of work. 

One of the issues with it is intermingling primary trust flow vs the secondary trust flow. Primary trust flow is about the RP trusting the Attesters, the main point of attestation. Secondary is primarily about confidentiality while achieving the primary goal of attestation. I think every subsection of section 7 needs to address both and be clear which it is addressing when it does. I think TLS is good enough for the confidentiality in the secondary trust flow; attestation can be used, but is not needed.

The other issue with section 7 is that I think it needs to say that Verifier trust in an Attester is almost always about attestation keys and that is it transitive through the Endorser. The only case where it is not is when they are connected by trusted HW, for example on the same bus, and that is usually not the reason to deploy attestation.

Also, I think the distinction between Attestation and TLS/HTTPS needs to be described in the document. Say why we need Attestation given we have TLS.

I added a new PR with with an Appendix B with System Examples that I think is very helpful.

I will keep working on PRs to address these, but it won’t happen super quick. It doesn’t have to be me addressing them. I realize I may be in the rough on some of these, but this is my thought on how close to done this is.

I suppose this can go out to the main WG and these things can get addressed there. 

LL

> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 16 Sep 2020 18:09:00 +0000

See my comments inline beginning with NMS>.

    One of the issues with it is intermingling primary trust flow vs the secondary trust flow. 

NNS> The objective of this section is to highlight the potential for trust semantics to occur in both directions. I think this is what your mean by 'primary' and 'secondary' trust flow? It isn't trying to exhaustively describe the various nuances of how a protocol or implementation might resolve the tension. 

	Primary trust flow is about the RP trusting the Attesters, the main point of attestation. Secondary is primarily about confidentiality while achieving the primary goal of attestation. I think every subsection of section 7 needs to address both and be clear which it is addressing when it does. 

NMS> I think it may not be possible to achieve full clarity outside the context of a particular protocol. So this may be a case where less is more. It already points out that confidentiality protection may be needed if attested values are privacy sensitive. That implies there is some basis for trusting confidentiality keys (which possibly already exists in a given context or protocol). The arch draft should be careful not to bias toward a particular confidentiality technique or technology IMO. 

	I think TLS is good enough for the confidentiality in the secondary trust flow; attestation can be used, but is not needed.

NMS> I don't think it is an intention of the architecture to identify or recommend any particular solution for confidentiality protection.

NMS> Words like "almost always" and "usually" are problematic because future use can change from current use rendering the architecture document content qualified in this way to become biased against whatever becomes common practice. If these words are omitted, does the recommendation in the above two sentences still make sense? 

Unpacking this a bit more:
"Verifier trust in an Attester is about attestation keys"
This is correct but too narrow as attestation is also about claims related to the environments that process other functions and protect other objects besides keys.

"[attestation of keys] is transitive through the Endorser"
This may be true if certain conditions also exist such as whether or not the key existed at the time of manufacturing such that the Endorser is able to make a claim about it. However, some hardware doesn't allow the Endorser to know the key or keys are not yet created at the time the Endorser is in possession of the device. The claims the Endorser supplies will have semantics that reflects these nuanced differences.

"The only case where it is not is when they are connected by trusted HW, ..., not the reason to deploy attestation"
I disagree with this characterization - of when it is not appropriate to do attestation. 

NMS> The architecture is trying not to endorse or specify a particular conveyance mechanism / protocol whether for moving around attestation messages or for providing confidentiality protections. This distinction seems to be clearly made in the sections on conveyance and messages. If we begin listing protocols that could be used for conveyance we have to ask when we should stop listing them and what it means if we happen to exclude one. 

If the assertion you're making is that TLS and protocols on top of it such as HTTPS are already implementing attestation conveyance then that seems incorrect as existing standards don't describe how Evidence is conveyed. There may be several ways to tunnel Evidence through TLS handshake or layer on top using extensions to HTTPS, or claims are conveyed as Endorsements / Reference values etc. but a draft explaining how to do this is warranted. It seems inappropriate for the arch draft to do it. 

-Ned

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 17 Sep 2020 12:17:39 -0700

> On Sep 16, 2020, at 11:09 AM, Smith, Ned <[email-masked]> wrote:
> 

So the Attester subsection didn’t mention the primary trust flow at all and it is probably the most important participant in primary trust flow. I’ve add a PR <https://github.com/ietf-rats-wg/architecture/pull/149> to address this. More an issue of basic completeness than exhaustive description and nuance.

> NMS> I don't think it is an intention of the architecture to identify or recommend any particular solution for confidentiality protection.

Right now it recommends reverse direction attestation. I’m happy to not mention any solution. If that is the goal then the text on reverse direction attestation for confidentiality should be replaced with more general text. Such a replacement would make the document simpler and cleaner and more general. An issue <https://github.com/ietf-rats-wg/architecture/issues/136> is open for this.

> This is correct but too narrow as attestation is also about claims related to the environments that process other functions and protect other objects besides keys.

Claims and such can add to the way a Verifier trusts an Attester, but only after trust based on the key is established.

> This may be true if certain conditions also exist such as whether or not the key existed at the time of manufacturing such that the Endorser is able to make a claim about it. However, some hardware…

I think the Endorser is responsible for setting up the key material. If not the Endorser, then we need to add a new box to the diagram for the entity that is responsible for setting up the key material.

Maybe the big difference in perspective for me is that TEE’s don’t come with keys and we have to work hard to put them in. We just don’t buy TPMs with keys preprogrammed. I also see the TPM and its keys as sort of equivalent to the TEE and fundamentally the subject of this draft. Someday I hope there will be a different kind of TPM that is an implementation of this draft and of EAT.

> NMS> The architecture is trying not to endorse or specify a particular conveyance mechanism / protocol whether for moving around attestation messages or for providing confidentiality protections. T…

Agreed.

> If the assertion you're making is that TLS and protocols on top of it such as HTTPS are already implementing attestation conveyance then that seems incorrect as existing standards don't describe ho…

I think the draft has to answer the question “why do we need attestation when TLS is in wide use today”? Part of the answer is what you write, there’s no claims conveyed in TLS. Another is that Attestation authenticates implementations (HW and SW) where TLS authenticates services and organizations (that can used any HW and SW). See this issue <https://github.com/ietf-rats-wg/architecture/issues/134>.

LL