Message-ID: <57ff8532-ffa7-4dfc-8f51-2bb8764e4a25@gmail.com>
Date: Thu, 9 Jan 2025 09:25:11 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: rats@ietf.org
References: <4ffdd034-05ec-4565-9cad-b40ff82f83fc@tu-dresden.de>
 <061efb99-89ef-4f4a-a9d7-0e41b4c97623@tu-dresden.de>
 <4099D519-7A37-4083-A8FF-C84065155CCE@tzi.org>
 <PH0PR11MB5176B7EDB6FCF245A8203EF5E5092@PH0PR11MB5176.namprd11.prod.outlook.com>
 <1060115c-7984-4c54-bc4d-903e5283a963@tu-dresden.de>
 <9a30a850c3d34f2fa0b614035ae4a134@huawei.com>
 <6c8ccd3f-4186-4958-a916-3e627709e55c@tu-dresden.de>
 <2ae4aec812e04d8aab44aac53781fcae@huawei.com>
 <0B1D3D34-3D4D-4DF1-A125-8CF4AFAA4C6A@island-resort.com>
 <3f1efaff-db26-4e54-b26b-d74a6dc140c3@tu-dresden.de>
 <272FC0C8-A49A-46D6-B9B1-67127FABC0A3@island-resort.com>
 <34b8ea44-e4b7-4024-873b-e939717c6259@tu-dresden.de>
 <2E15F514-29BF-4763-A844-5E38CDEF5791@island-resort.com>
 <17359f9b-914e-4d3d-8923-92bdf2cc887e@tu-dresden.de>
 <983AE2D0-D1CF-43F6-8888-F6D0487B4B8E@island-resort.com>
 <bf973538-b390-4c60-8c99-7a93f00c3833@tu-dresden.de>
 <F78D9011-E0A8-43E6-A1BA-DDA44BF24348@island-resort.com>
Content-Language: en-US
From: John Kemp <stable.pseudonym@gmail.com>
In-Reply-To: <F78D9011-E0A8-43E6-A1BA-DDA44BF24348@island-resort.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: LNNVPEAEYCDQGAZZZDYYSQBL5UAFFDQ3
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_Security_considerations_of_remote_attestation_=28?=
 =?utf-8?q?RFC9334=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/scZ9C6eOaz5jLBTGF6gB7pjEToE>

I can't tell whether this is important specifically for this discussion, 
but:

On 1/8/25 9:19 PM, lgl island-resort.com wrote:
> A detour for the purpose of framing:
> 
> The reason attestation is so important for client devices is that end 
> user people are entirely untrustworthy.

The reason attestation is so important for servers is that servers, CAs 
and other assumed-trusted components are often less trustworthy than 
assumed, or indicated by their issued certificates alone.

> The person using a mobile phone 
> or a FIDO authenticator is not a security professional, doesn’t want to 
> update their software and can be duped.  

CAs mis-issue certificates, servers and services get compromised, and 
users should not assume their interests are aligned with those of the 
operators of those servers.

> Banking services, distributors 
> of important documents and such want to know the device the user is 
> using behaves. They can NOT rely on the user to assure that.

Users cannot rely on the operators of servers keeping their personal 
information secure, nor can they rely on X.509 certificates issued to 
servers to indicate that they can trust the server wielding such 
certificates.

> 
> This makes it critical that the attestation key is entirely different 
> from what ever authenticates the end user person. The attestation key 
> has to be associated with the device maker, never the end user person.
> 
> I started in this thread thinking the same distinction was important for 
> server/services, but maybe not...

I don't know. I think that such distinctions may indeed be as important. 
Or at least, I don't believe users or devices should blindly trust 
services or servers any more than the latter should blindly trust the 
former. As mentioned, I'm not sure whether my comments on this framing 
are important for the purposes of this particular discussion and I do 
not want to derail it, but I also do believe that authenticating servers 
and services is as important as authenticating users and user devices 
and services. Attestation should be possible in both directions.

Regards, John

John Kemp
Independent Security Architect
t: +1.413.645.4169
e: stable.pseudonym@gmail.com

> 
> 
> 
>> On Jan 5, 2025, at 4:48 AM, Muhammad Usama Sardar 
>> <muhammad_usama.sardar@tu-dresden.de> wrote:
>>
>> I think we are getting closer. I do appreciate that you want to be 
>> inclusive by saying "keying material" to include HMAC-like solutions 
>> but just to understand each other better, let's be more precise about 
>> the keys - the way we put it in draft can be different. Below I am 
>> assuming a remote attestation solution based on digital signatures. At 
>> a high level, there are three main keys:
>>
>> 1. Attestation Key (AK): It is used for signing attestation claims.
> 
> It also must identify the implementor of the attester so a verifier can 
> decide if they are trustworthy.
> 
> draft-fossati-tls-attestation section 1 says:
> 
>     Attestation [RFC9334] is the process by which an entity produces
>     evidence about itself that another party can use to evaluate the
>     trustworthiness of that entity.
> 
> That’s not very good because the entity could be lying. You also need to 
> know the entity is trustworthy. That happens through proved identity and 
> out-of-band information that the identified entity is trustworthy.
> 
>> 2. TLS Identity Key (TIK): Ephemeral Key (EK): It is a key generated 
>> within a TEE and its public part is signed by AK. However, the TLS 
>> peer (TLS client in my case) has no prior knowledge about this key.
> 
> This is an internal part of TLS protocol, right?
> 
>> 3. TLS Identity Key (TIK): Long-term Key (LTK): It is the key bound to 
>> the machine's long-term identity (assigned name/FQDN etc.) and it is 
>> the key which is typically used to provide "authentication" in 
>> standard (non-PSK based) TLS protocol.
> 
> For the common public Internet use of TLS, I’d describe this as the 
> https service provider key. If you paid widgets.com and they didn’t send 
> your package of widgets you know who to go after. It’s not really about 
> a machine or even a key because the machines and keys for https:// 
> widgets.com will come and go.
> 
> I’d say that these keys actually authenticates the legal entity, the 
> people that work there, its business practices and such (e.g. Widgets 
> Inc.). When you decide to pay widgets.com, that’s what you have in mind.
> 
> So, yes, we’re reasonably in agreement on keys. :-)
> 
> 
>> Based on this, please see inline:
>>
>> On 05.01.25 05:38, lgl island-resort.com wrote:
>>>> IIUC you are describing TLS client as attester while I had TLS server as attester in my mind. This is partly because we have done the formal analysis of the latter [1], while only some initial specification work for the former.
>>> Seems like we can do attestation in either (or even both) directions with TLS.
>>
>> Sure. I am really sorry if it came across wrong. I didn't mean to say 
>> that the TLS client as attester as well as mutual attestation are not 
>> possible. They are perfectly legitimate cases with TLS. In fact, 
>> draft-fossati-tls-attestation includes all these cases.
>>
> Absolutely no worries here. It’s a good discussion.
> 
>> I intended to say that TLS client as attester and mutual attestation 
>> are currently work-in-progress from formal verification perspective. I 
>> do not expect a major change in results for these cases but I wanted 
>> to stick to TLS server as attester for which we do have better 
>> understanding as well as results of formal verification. It is also a 
>> typical case in confidential computing.
>>
>>> I understand from [1] that there maybe some TLS protocol issues, but what’s interesting to me is the key material of something like RA-TLS. I don’t understand what the thinking is for this yet.
>>
>> Can you clarify the key material for which of above keys (1, 2 or 3) 
>> you were interested in? Also, I suspect you are interested in the Key 
>> Derivation Function (KDF) of the key, right?
>>
> 1 and 3 because I’m interested in the ownership, life cycle and policies 
> for the keys. Pretty sure I’m not interested in the KDF.
> 
>>
>>> I think the purpose of https key material is to authenticate that bigbank.com really is Big Bank Corp and that it is distinct from attestation key material provided by Intel, Qualcomm and such vendors.
>>
>> Here is my understanding (please correct me if I am wrong):
>>
>>   * "https key material" refers to 3 above
>>   * "attestation key material" refers to 1 above
>>
> Yes
> 
>>>> Anyway, trying to map what you said to my scenario: Intel develops an attester (e.g., TDX), installs key pair AK and publishes public key via website. But at the time when this attester leaves Intel factory, neither the location of attester where it will run nor the organization which will control this attester is known. Both may be important for regulatory purposes, such as processing of medical and financial data.
>>> An attester isn’t really an attester until someone controls it, right?
>> I don't think so. I think there is always someone who can control it. 
>> For example, Intel is in full control until some new owner (purchaser) 
>> assigns it a new identity.
> 
> Right. It is likely always under control of someone, but the policy and 
> semantics may change with an ownership change.
> 
>>> Same as a key pair someone generates. A key pair isn’t interesting or useful until we know who owns the private key and what they will sign with it. Sorting out ownership hand-offs seems complicated. I think Ned was trying to describe what to do.  Seems that this could be difficult to standardize and end up very vendor specific.
>>>
>>>> For security properties, I am thinking about [2], e.g., Server authentication. The software and hardware can be "attested" but the server "authentication" does not hold because the long-term identity (machine identity: assigned name/FQDN) is never used in the protocol you mentioned. Please correct me if I misunderstood something in your reasoning.
>>> The question I have is whether the https service provider key material for bigbank.com is somehow made to also serve as attestation key material.
>> Assuming the following (please correct me if wrong):
>>
>>   * "https service provider key material" refers to 3 above
>>   * "attestation key material" refers to 1 above
>>
>> Both yes and no :) depending on the protocol, see below
>>> If yes, how?
>>
>> Depending on what exactly you mean by "also serve as" (please clarify 
>> further if I am misinterpreting), two relevant examples are attested 
>> CSR [3] and attested TLS [4]. I believe (haven't evaluated formally 
>> yet) the former, with passport model, has weak security guarantees. 
>> The latter, however, has technical limitations as CertificateVerify 
>> message of TLS is not extensible and you can provide proof-of- 
>> possession of only one key [5]. So, with [4] you can have either 
>> "attestation" or "authentication", but not both.
>>
>>
>>> If no, then what key material is used for attestation?
>>
>> RA-TLS [1] is an example here. It uses 1 for attestation.
>>
>> The protocol never uses 3. My point was that such protocols which use 
>> only 1 and 2 (and not 3) can only provide "attestation" of software 
>> and hardware but cannot provide "authentication" of who is in control 
>> of the machine and where it runs. Do you agree?
>>
> Yes, I do agree.
> 
> This is still thinking-in-progress, but maybe the first thing to be 
> clear about for a given attested TLS design is whether it can support 
> separate keys for 1 and 3. We could define:
> 
>     Split server-auth and attestation — Does both server auth and
>     attestation and uses a different key for each
>     Merged server-auth and attestation — Uses the (very common) server
>     auth key to do both attestation and server auth
>     Attestation-only — Only one key and it does attestation, never
>     server auth
> 
> 
> Maybe for the next round of email: a description of the security 
> disadvantages of merging server auth and attestation.
> 
> LL
> 
> 
> 
>>>> [1]https://ieeexplore.ieee.org/document/10752524
>>>>
>>>> [2]https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1
>>
>> [3] https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/
>>
>> [4] https://www.ietf.org/archive/id/draft-fossati-tls- 
>> attestation-08.html#name-attestation-alongside-x509-
>>
>> [5] https://github.com/tls-attestation/draft-tls-attestation/issues/73
>>
>> [6] https://ieeexplore.ieee.org/document/10373038
>>
> 
> 
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org