Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

[Laurence Lundblade <[e-mail]>]

> On Jun 1, 2022, at 2:27 PM, Eric Voit (evoit) <[e-mail]> wrote:
> 
> Hi Laurence
>  
> While I do recognize the text has been tweaked since earlier this year, many foundational questions about the claim remain.  My recommendation is to review the previous dialogs and address the questions/comments. 

See below.

Some questions were old and already addressed (e.g. confusion with certification). Other’s were past misunderstanding on the part of the commenter. Some of the concerns below are duplicate of each other.

The main valuable result in my comments below is to clarify that security-level is to characterize the designed security level of the attester, not the output of an evaluation relative to SW update and exploits. Security-level is definitely not intended to be a major part in Attestation Results.

I believe I have provided a reasonable answer to the concerns below.

LL



> Some of these include:
>  
> Adrian:
> "Why would a verifier choose to rely on this instead of some information that comes directly from an Endorser? Without an example, it just seems a better fit for an endorsement."
> https://mailarchive.ietf.org/arch/msg/rats/KRVoK0ITFnKhhKUz2sgkg7qhl1c/ <https://mailarchive.ietf.org/arch/msg/rats/KRVoK0ITFnKhhKUz2sgkg7qhl1c/>
See my recent comment on Evidence and Endorsements. I believe this <https://mailarchive.ietf.org/arch/msg/rats/DBQVqJ1xtNybIw53A2REVdPqgdk/> answers this.


>  
> Michael:
> " I would like security-level removed from the base spec."
> https://mailarchive.ietf.org/arch/msg/rats/VWjh47bxm-aNLeQfqub1kIhy0Uk/ <https://mailarchive.ietf.org/arch/msg/rats/VWjh47bxm-aNLeQfqub1kIhy0Uk/>
That comment was in the context of security-level being redundant with DLOAs. I think we have shown that it is not. There is text in  draft-13 that clarifies it is not a DLOA.


>  
> Ned:
> "the namespace delivered needs to be able to differentiate between all three security-levels described above."
> https://mailarchive.ietf.org/arch/msg/rats/iSgLo-CmaUP40Jo0A0uDnj7X1q8/ <https://mailarchive.ietf.org/arch/msg/rats/iSgLo-CmaUP40Jo0A0uDnj7X1q8/>
This comment seems to be about security-level characterizing the security of 1) the Endorser itself, 2) the Attester itself and 3) the Verifier itself.

This is a bit of an unexpected application of security-level to me, but in draft-13 it is made clear by the new sections structure that security-level only ever characterizes the Attester.


> Henk:
> "I am increasingly having doubts about the current definition of "security-level" and I think I am as least as confused as Eric, Ned, and Wei are. Which raises a big red flag for me"
> https://mailarchive.ietf.org/arch/msg/rats/Iwy_d3bnzSmLy6VFvgclWyUvOKQ/ <https://mailarchive.ietf.org/arch/msg/rats/Iwy_d3bnzSmLy6VFvgclWyUvOKQ/>
About half of the commenters here are not confused and support security-level. Security-level is not a  total confused mess.

Maybe draft-13 fixed the confusion? Concrete comments needed for action here.


>  
> Panwei:
> " To me, the “security-level” seems like redundant with the DLOA claim"
> https://mailarchive.ietf.org/arch/msg/rats/JVDgKRB6MU5UoFEKTavU7pEoxW4/ <https://mailarchive.ietf.org/arch/msg/rats/JVDgKRB6MU5UoFEKTavU7pEoxW4/>
Same comment / context as Michael’s above.


>  
> Thomas:
> "I don't think we'd use it, mostly because of the self-asserting nature of such claim."
> https://mailarchive.ietf.org/arch/msg/rats/5_42_KKVvn4Xvx5W5ygs-PgK22M/ <https://mailarchive.ietf.org/arch/msg/rats/5_42_KKVvn4Xvx5W5ygs-PgK22M/>
This is by one person and most claims won’t be used in some use cases so this comment doesn’t really have much weight. 


>  
> Eric:
> "The meaning of security-level varies across the use cases below (i.e., in some cases it is a self-appraisal, in others it is calculated by the Verifier.)"
> https://mailarchive.ietf.org/arch/msg/rats/P75I4YZFcTqnAkA3R1fjccbOX6Y/ <https://mailarchive.ietf.org/arch/msg/rats/P75I4YZFcTqnAkA3R1fjccbOX6Y/>
Yes. You have to know the Verifier’s policy, just like with everything else the Verifier outputs.


> " Why would a Relying Party coder ever want the Endorser and the Attester's security-level if it has been given the Verifier's security-level?"
> https://mailarchive.ietf.org/arch/msg/rats/tD1Xa5URqB5e9yttjyaWpzvS63U/ <https://mailarchive.ietf.org/arch/msg/rats/tD1Xa5URqB5e9yttjyaWpzvS63U/>
This is the same comment and context as the Ned comment above.


> "Here are a few off the top of my head..."
> https://mailarchive.ietf.org/arch/msg/rats/eGqHwo47RQj5FJDCd8ukxCNhWcA/ <https://mailarchive.ietf.org/arch/msg/rats/eGqHwo47RQj5FJDCd8ukxCNhWcA/>
> *	What should be a score is Firmware is known to be out-of-date, deprecated, and there is an active exploit.  
The claim is to characterize the designed strength of the Attester. It is not to characterize the overall result of an evaluation or the output of a Verification. So the claim doesn’t really speak to this issue.
>  
> 
> *	Is all Hardware equal even if (a) one can scan and deliver signatures spanning a nonce and real, current firmware measurements  (b) another can be programmed by a hacker just to spit out a pre-programmed value.  

Text added in draft-13 clarifies that security-level is only a rough characterization. It also justifies why it is only a rough characterization.

> 
> *	Is bios configuration part of what should be considered in the level?  How can a Relying Party hope to keep up with which bios configurations might open up security exploits.

Security-level is primarily to characterize the attester design intent, not to track the state of SW updates, exploits and such. It is not intended for a summarization of the output of a Verifier.  Other claims AR should be defined for that. 

It may still occur in the output of a Verifier as a claim that is forwarded by the Verifier.

Personally, if I were an RP and the firmware were out of date or there were known exploits, I’d probably wouldn’t want some sliding scale rating for that. I think I’d want the Verifier to make a recommendation to trust or not trust, or the Verifier to tell me explicitly what is wrong. To me that is further reason why security-level is not really about characterizing the exploit/update state of a device.

We can add text that clarifies that security-level is about attester design intent, not current disposition relative to exploit/update.

LL



>  
>  
> Eric
>  
>  
> From: Laurence Lundblade <[e-mail]> 
> Sent: Wednesday, June 1, 2022 5:17 PM
> To: Henk Birkholz <[e-mail]>
> Cc: Eric Voit (evoit) <[e-mail]>; Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
> Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)
>  
>  
> On Jun 1, 2022, at 2:06 PM, Henk Birkholz <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Laurence,
> 
> I see that the list of values for security-level has been trimmed, the context had quite some churn that is hard for me to reflect here in detail. What I am really missing now is the most important statement: "The claim made here is solely a self-claim made by the Attester.”
>  
> You suggested text would quite work out right.
>  
> - It could be a claim made by Verifier in AR and thus not a self-claim. (But only if this is a useful in the particular AR use case; some RP/Verifiers may prefer certification info or define their own scheme for security level; it’s just there if you like it and find it useful, not as any canonical standard representation of Verifier output)
>  
> - Even if it is a self-claim, so are many of the other claims
>  
> - In some cases when it is a claim made by the Attester, the Verifier may have rules for checking it when forwarding it to the RP, just like it has rules for all the other claims it may forward to the RP from either the Attester or Endorser. For example it might know the device manufacturer is very scrupulous and will only puts the correct security-level in just like it knows it puts in the correct UEID.
>  
> LL