[Rats] Re: Clarifications in draft-ietf-rats-eat

[Laurence Lundblade <[e-mail]>]

> On Apr 21, 2025, at 6:14 AM, Muhammad Usama Sardar <[e-mail]> wrote:
> 
> Hi Laurence,
> 
> I am happy that we could have a technical discussion independent of RFC.
> 
> One question; mostly agree with the rest. Please see inline.
> 
> On 21.04.25 03:49, Laurence Lundblade wrote:
>> I often do not know what someone means when they use the bare term “authentication” — who’s authenticating who based on what secret for what purpose?
> Purpose may be hard to put in there in the definition; otherwise I like that. It is nice and precise.
>> Just looked at draft-ietf-rats-reference-interaction-models, which I hadn’t looked at before. Yes, that authentication is absolutely required, but it’s not the same as TLS server auth.
> If we consider the case of TLS server as RATS Attester, then what is the difference? The section does mention "by using a secure channel including authentication" So TLS should be one way to do it.

I believe it’s in the keys more than the protocol. In particular the policy, legal agreements, processes and expectations around the keys.

TLS web server auth hinges on business process carried out by CA’s and Internet providers. They issue keys to entities that show they own a domain name. The private keys are used in primarily web servers. The root public keys are distributed in browser software. It’s a whole ecosystem.

Attestation keys have a different and distinct ecosystem that centers around manufacturers of HW, SW, systems and such. Often the most fundamental keys are established in a chip fab.

For TLS client auth, the ecosystem is often run by big security-oriented government organizations. For example, in the US there are PIV/CAC cards for US government employees.

Sometimes I think about it in terms of who you would blame/sue/prosecute if the private key was compromised. Who’s financially and legally responsible for protecting the keys. It’s not the same for attestation as it is for TLS web server authentication.


>> I would call the "Authentication Secret” an “Attestation Key” to avoid the ambiguous term that “authentication” is.
> I agree.
>> 
>> Maybe we need a rule that terms like “root” and “authentication”, “key” and “trust” be qualified with at minimum one adjective. The term in  draft-ietf-rats-reference-interaction-models becomes "attester-verify authentication”. Anyone on this list caught using the bare terms has to take notes at the next interim meeting. Just a thought :-)
> Good idea. But perhaps exclude when someone is quoting someone else's draft, otherwise I will be the note taker forever :)

Yes, only applies to the original user of the bare term, not those quoting.

LL