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

[Laurence Lundblade <[e-mail]>]

Hi Usama,

Yeah, I’m very focused on getting EAT out the door because little things can add many months of delay… and happy to have a discussion independent of that.

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? In the paragraph in question it says “server authentication” to reference common TLS use and “user authentication” to reference password authentication and such.

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. Personally, I would change draft-ietf-rats-reference-interaction-models to not use the term authentication that way. I would call the "Authentication Secret” an “Attestation Key” to avoid the ambiguous term that “authentication” is.

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 :-)

I did acknowledge your sentence quoted next was correct.

For attestation, the keys are typically injected by the hardware manufacturers. The keys may also be derived from a seed injected by hardware manufacturers at the manufacturing time.
This key derivation may involve additional factors, such as the current state of platform TCB, as well as a random value selected by the platform owner [1, Section 3.5].

Hope that helps...

LL

 

> On Apr 18, 2025, at 3:07 AM, Muhammad Usama Sardar <[e-mail]> wrote:
> 
> Hi Laurence,
> 
> TL;DR: I think I mentioned it a few times not but just to clarify yet again: I would like to discuss but not delay the RFC. So please read the following with a peace of mind that I just want to understand your perspective, and its implications on attested TLS.
> 
> ---
> 
> Unfortunately, what you have presented so far are non-technical reasons, i.e., nobody will stop using SGX because of this, or base their provisioning architecture on this, or that WGLC has concluded. 
> 
> On the other hand, I wanted to have a technical discussion on this, i.e., to understand your real reasoning on the differences in your mind. For example, reference interaction models draft [1] claims that "authentication" is an essential requirement for remote attestation and you are claiming that the two are completely different. How do the two things fit together? It seems quite reasonable to me to have this discussion without delaying the RFC.
> 
> You write "To give an example of one aspect of the difference" and you leave me curious if there is any other difference at all? If yes, what is that?
> 
> Also please see inline below:
> 
> On 18.04.25 02:48, Laurence Lundblade wrote:
>> 
>> 
>>  The purpose of this paragraph is to provide a very high-level brief characterization of attestation. 
> I find the paragraph inviting more trouble than being helpful. This purpose could have been easily achieved without comparison with "authentication".
>> I worked pretty hard to wordsmith it and keep it brief without going down the slippery slope of a full discussion of attestation. The idea was to say enough to get the readers attention that goals are not the same and to direct them to RFC 9334 for the details. It occurs very early in the document. I have a strong opinion that the level of detail you asking for doesn’t belong in this paragraph or this early in the document.
> I am not asking to put in all that detail in the paragraph. I just wanted to present you one concrete counterexample with a concrete reference to SGX where your text is wrong.
>> I am opposed to change here. I doubt any further discussion will change my mind. I expect publication in a week or so.
> I don't understand why you always bind the discussion with the change in draft. The two need not be necessarily bound together. The discussion is not to change your mind, it is to read your mind. 
>> I am trying to be respectful by giving you the message directly rather than the document just getting published without the change you want.
> Appreciate that. I'll create errata as soon as it is published and discuss it at interim meeting. 
> 
> 
> [1] https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-13.html#section-4
>