[Seat] Re: [Rats] Re: [WIMSE] Re: Re: Re: Re: Follow-up of meeting 122 presentation (Formal proof of insecurity of Intel's RA-TLS and draft-fossati-tls-attestation)

[Muhammad Usama Sardar <[e-mail]>]

# TL;DR: Proposed edit to definition in [1]. Submitted PR [2]. Published 
draft [0] as background for discussion.

# Details:

Meanwhile, I took the time to publish a draft [0] putting together a 
high-level overview of analysis as background to this discussion.

Just as a quick recap of 3 options I proposed [3]:

*Option # 1* was to remove attestation. Folks seem to want it; fine for me.

*Option # 2* was to preferably use some other term or define attestation 
more precisely. Folks seem to insist on reusing attestation. While I 
believe it will add a lot of confusion and unnecessarily reduce SEAT's 
opportunity to collaborate with WIMSE in future, I can live with that.

WIMSE folks seem to have settled at some definition. Looking at the 
current definition of attestation of WIMSE in PR [1], I have proposed a 
small edit there.

One nit: Definition says "Attestation in WIMSE is intentionally defined 
quite broadly" but I don't see what exactly is broader than RFC9334. 
What is additional to RFC9334 needs to be precisely mentioned explicitly 
here.

 1. Attestation of RFC9334 also does not rely on any specific
    communication protocol. It can be used with TLS, EDHOC, IKEv2, SSH
    etc. So you don't actually need to say that part, and in my proposed
    edit, I removed that part.
 2. What exactly do you mean by "implementation"? Is it meant to include
    software-based attestation vs. hardware-based attestation. My
    proposed edit is under this assumption. If there is something in
    addition to that, please specify that to disambiguate as cleanly as
    possible.

Now, the definition is broader than attestation of RFC9334, i.e., 
attestation of RFC9334 remains explicitly in scope. So things seem to be 
moving towards my 3rd option.

*Option # 3* was to inform the implementers about these attacks. I have 
submitted a PR [2] for this, which is a slight variant of the text I 
proposed in [3]. Feel free to propose some wordsmitthing as you like, 
but not informing implementers about known attacks is a real disservice 
to the community. Given a set of hypothesis that:

  * most WIMSE deployments use TLS, and
  * TLS is explicitly mentioned in draft, and
  * attestation is mentioned too, and
  * attestation of RFC9334 is in scope, and
  * that there are only three top-level categories of combination of
    remote attestation and TLS [0];

it implies to me this is basic guidance to mention these attacks, and 
not a detail.

Thanks.

-Usama

[0] https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs-post/

[1] https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/pull/111

[2] https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/pull/113

[3] https://mailarchive.ietf.org/arch/msg/wimse/I0YgR9AzKcA0zF_kG7Q6mWCc9ZY/