[Rats] Re: Security considerations of remote attestation (RFC9334)

["Panwei (William)" <[e-mail]>]

Hi Usama,

In the draft you provided,
    > [1]
    > https://muhammad-usama-sardar.github.io/rats-unprotected-evidence/
    > draft-usama-rats-unprotected-evidence.html
It is said that,
    Section 7.4 of [RFC9334] has:
       A conveyance protocol that provides authentication and integrity
       protection can be used to convey Evidence that is otherwise unprotected
       (e.g., not signed).
    Using a conveyance protocol that provides authentication and integrity
    protection, such as TLS 1.3 [RFC8446], to convey Evidence that is otherwise
    unprotected (e.g., not signed) undermines all security of remote attestation.
    Essentially, this breaks up the chain up to the root of trust.

First, I feel you may give more explanations here for the readers to better understand your idea, maybe an example would also be good.

Second, after more thinking of this, plus with the relay issue you mentioned in IETF 121 meeting, I think I can understand your point here, i.e., the mismatch of the actual source of Evidence generation with the source of Evidence conveyance.
In our products' real case, the Evidence is signed by the TPM in the device, while another module in the same device establishes the conveyance channel. The Evidence needs to be protected (signed). The Verifier will check the identity information in the TPM LAK certificate that signs the Evidence and in the certificate used to establish the secure channel that conveys the Evidence, to ensure the source of Evidence generation and the source of Evidence conveyance are the same device.
If the secure conveyance channel is established direct from the root of trust to the Verifier, i.e., the certificate of signing the Evidence is also the one used for establishing the secure channel, then the Evidence signing may be omitted and redeemed by the authentication and integrity protection of the conveyance protocol.
This is just my understanding, and I may misunderstood your point.

Regards & Thanks！
Wei PAN (潘伟)