[Last-Call] Re: draft-ietf-satp-core-17 ietf last call Secdir review

[Ionut Mihalcea <[e-mail]>]

Hi Michael,

> On 17 Oct 2026, at 14:25, Michael Richardson <[e-mail]> wrote:
>
> That suggests to me that the Remote Attestation flow has not taken into
> account the need for freshness.
>
> If freshness is established by Nonce, then the Verifier would need to pass a
> nonce in the other direction, prior to creation of evidence, and this would
> effectively prevent such a on-path attack on the evidence.
>
> OTH, if a "broadcast" epoch ID is used for for freshness, then it may well
> be that absent other binding of evidence to the host, such a substitution
> could be made.


[IM] The remote attestation protocol is not described (perhaps I made it sound like it is), nor its relationship with the SATP Core protocol, beyond a mention that RA can be used before this protocol starts to verify the state of the two gateways. I think not describing the RA exchange in detail is sensible. However, in more abstract terms I agree with you: the security properties / guarantees offered by RA and under which the RA protocol should be performed (e.g., the need for freshness) need to be encoded normatively somewhere. It may well be that the existing implementations make robust use of RA, I'm only thinking about these requirements as a cross-layer contract.