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

Laurence Lundblade <> Thu, 17 September 2020 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84C323A0838 for <>; Thu, 17 Sep 2020 12:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sgV0BUHBuKwr for <>; Thu, 17 Sep 2020 12:17:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A5E13A082F for <>; Thu, 17 Sep 2020 12:17:40 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id IzPXkDPYnt827IzPXkQKQz; Thu, 17 Sep 2020 12:17:40 -0700
X-CMAE-Analysis: v=2.3 cv=MfYSRK3f c=1 sm=1 tr=0 a=bDV9F4HViGxlAqk2TtlXQA==:117 a=bDV9F4HViGxlAqk2TtlXQA==:17 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=K6EGIJCdAAAA:8 a=0XtbOteLAAAA:20 a=J9ASZmEBsvg-_CMTJB4A:9 a=q2WTOrNZsUn86n72:21 a=3Uniq_fpaLUj9FcI:21 a=QEXdDO2ut3YA:10 a=UipC7NfFPZhd6C5PzDYA:9 a=7LUy174O8deIdq3A:21 a=5BmQX5vOuTGOO6Sy:21 a=eLmHcAQ2UINlKPgC:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5F6720B-E9EE-4A3A-898F-698C6DF405C3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 17 Sep 2020 12:17:39 -0700
In-Reply-To: <>
Cc: Michael Richardson <>, Henk Berkholz <>, Dave Thaler <>, "Panwei (William)" <>, "" <>
To: "Smith, Ned" <>
References: <5786.1599579936@localhost> <> <>
X-Mailer: Apple Mail (2.3608.
X-CMAE-Envelope: MS4wfJiSgfQ8afnubusPOsroJiTXHJZbctVyYOjCj8kv6/06SmIZUZaqGnwuLaaYDwiqCLUNpirbI+P2t0pm+axZb+mw9C/dkdMvt2kxy3rW/mSzaouqj1YV emA5lBSrIocywA3iaWpxkwKL8EXvkKK+0vXk8ufXk7782vFHgIbi4gptxvDCUXC54UMsTWgabmsUPCyUtuj+cbAjCIxJr+blGJyaX0M8WQaoe0PujYmJkwxl ThrVcx0IOc3qgJ8AMb0sGDQ13Ui9gBwMDql8Htp/5Mid5ZcjnTzmP/A7PuSXkcGd4vRMrMphfgUCRBCxujrR2nYB1+JvyFNWkCCSIAa/0jO29C7DQJTll7M4 eL932jIq
Archived-At: <>
Subject: Re: [Rats] disposition of remaining pull requests to architecture document
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Sep 2020 19:17:43 -0000

> On Sep 16, 2020, at 11:09 AM, Smith, Ned <> wrote:
> See my comments inline beginning with NMS>.
> On 9/11/20, 10:33 AM, "RATS on behalf of Laurence Lundblade" < on behalf of> wrote:
>> 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. 
> 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. 

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 <> to address this. More an issue of basic completeness than exhaustive description and nuance.

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

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 <> is open for this.

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

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

> "[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.

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.

> "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. 
>    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.
> 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. 

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


> -Ned