Draft: draft-ietf-rats-architecture

Commentary: Update section on - device attesters 
 This section , as put , is kind of a big leap , no ? I think the important part of this next level , is the introduction of a hardware root of trust like a TPM to eliminate the need to trust the device ’s operating system software in reporting attestation results . 
 How about " For strongest security , .... " to avoid confusion with high level OS . 
 This also already fixed by existing text . 1 ) This wording implies that there are other cases where it ’s acceptable to exfiltrate or modify keys . Do those still count as Attestation ? I know RATS must be ‘ inclusive ’ , but is it meant to include absolutely everything ? For example : If I had a router with the following features : A root password A serial number in a file owned by root TLS A shell script that computes the hash of the kernel and stores it in a file on startup A Show command that prints the serial number , software version string , date and the hash . … would I have a RATS - Compliant Attestation System ? It provides evidence The evidence is protected by encryption ( TLS ) There are a zillion different formats for evidence , so I assume ASCII strings count The Attesting Environment is protected by the root password Freshness is assured by the date , which in turn is protected by the root password . 2 ) The example goes on to say that this statement is not true ; you do n’t need process isolation . 3 ) What does a plastic case have to do with attestation ? 4 ) 
 The last three paragraphs have to be taken together as they 're describing three hardening levels ( ' low ' . ' medium ' , ' high ' ) . I do n't believe the goal of the security considerations is to define hardening levels . If so , it should be in a different part of the document . The preceding paragraph - " In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the Attester . For example the owner or user of a mobile phone or FIDO authenticator is not trusted . The point of remote attestation is for the Relying Party to be able to trust the Attester even though they do n't trust the user or owner . " - introduces the concept that the Attester 's domain isolation can have multiple levels of hardening . It would be cleaner to capture this idea as the security consideration . e.g. " The Attester 's domain isolation technique may have differing protection properties that rely on different hardening strategies . These differences can be accounted for by including endorsement Claims that describes protection properties and hardening strategy applied to the Attester " . Some examples may follow if that makes sense where the examples already provided seems to be : FIDO Process / app isolation ( aka memory ring protections ) physical housing TEE side channel attack mitigations
Paragraph (version A):
In many cases the user or owner of the device must not be able to
modify or exfiltrate keys from the Attesting Environment of the
Attester.  For example the owner or user of a mobile phone or FIDO
authenticator is not trusted.  The point of remote attestation is for
the Relying Party to be able to trust the Attester even though they
don't trust the user or owner.
Paragraph (version A):
Some of the measures for low level security include process or
application isolation by a high-level operating system, and perhaps
restricting access to root or system privilege.  For extremely simple
single-use devices that don't use a protected mode operating system,
like a Bluetooth speaker, the isolation might only be the plastic
housing for the device.
Paragraph (version A):
At medium level security, a special restricted operating environment
like a Trusted Execution Environment (TEE) might be used.  In this
case, only security-oriented software has access to the Attester and
key material.
Paragraph (version A):
For high level security, specialized hardware will likely be used
providing protection against chip decapping attacks, power supply and
clock glitching, faulting injection and RF and power side channel
attacks.
Paragraph (version B):
In many cases the user or owner of the device must not be able to
modify or exfiltrate keys from the Attesting Environment of the
Attester.  For example the owner or user of a mobile phone or FIDO
authenticator, having full control over the keys, might not be
trusted to use the keys to report Evidence about the environment that
protects the keys.  The point of remote attestation is for the
Relying Party to be able to trust the Attester even though they don't
trust the user or owner.
Paragraph (version B):
Some of the measures for a minimally protected system might include
process or application isolation by a high-level operating system,
and perhaps restricting access to root or system privilege.  For
extremely simple single-use devices that don't use a protected mode
operating system, like a Bluetooth speaker, the isolation might only
be the plastic housing for the device.
Paragraph (version B):
Measures for a moderately protected system could include a special
restricted operating environment like a Trusted Execution Environment
(TEE) might be used.  In this case, only security-oriented software
has access to the Attester and key material.
Paragraph (version B):
Measures for a highly protected system could include specialized
hardware that is used to provide protection against chip decapping
attacks, power supply and clock glitching, faulting injection and RF
and power side channel attacks.