Expat BOF

July 21, 2025

Note takers: Yaron Sheffer, Thomas Fossati

Agenda

05m WG introduction - Chairs
05m Problem statement - Chairs
05m Why not RATS/TLS - Paul Wouters (AD)
10m Problem to be solved - Yaron Sheffer
10m Use cases - Thomas Fossati
10m Design Space of attested TLS - Muhammad Usama Sardar
30m Open MIC discussion - Audience
05m BOF questions - Chairs
Rem Charter and Scope discussion - Chairs

WG introduction

Chairs

Problem statement

Chairs

Why not RATS/TLS

Paul Wouters (AD)

• both RATS and TLS were not quite the right place due to scope fit
• ISE and AD sponsored did not seem appropriate since it was a bigger
  problem that needed more views
• A separate group would allow both sets of participants to come
  together to work on the problem

Problem to be solved

Yaron Sheffer

• Dave Thaler: what's the expected lifetime of the attestation

  • to be discussed; Dave Thaler asks whether it is a requirement

• Stephen Ferrell: Who is the relying party.

  • could be either side

• Britta Hale: What is being attested? Are you authenticating the
  connection

  • Authentication of the TLS connection and the subsequent exchange

Use cases

Thomas Fossati

No questions.

Design Space of attested TLS

Muhammad Usama Sardar

• Richard Barnes: is timing really important (for attestation)? Once
  the security properties are established, there can be no change
  later unless the TEE is rogue. So pre-handshake may be sufficient.

  • The state of the platform could change while the (attested) TLS
    connection is ongoing

• Eric Rescola - trying to understand timing; don't understand what
  the guarantees mean. Understand idea of attesting to the old
  firmware before the update but not during the...it's related to the
  freshness of the evidence

  • Usama: time of check to time of use is a very hard problem to
    solve
  • EKR: then this solution is useless as the crypto keys should get
    destroyed when the change occurs

• Uri - want end2end security, but there are debates about proxies:
  there's either end2end security or you dont. With limitations to the
  post-attestation, application layer is not a limitation but a
  requirement

  • Usama: biz logic (if changes is needed) then it would be bad as
    solution should be agnostic to avoid changing all applications
  • Uri: in other words, you want a building block which is then not
    necessarily related to TLS, in fact, it shouldn't be depended on
    TLS but it requires a secure pipe

  • Hannes: thought about RATs, how attestations work. Looking at
    communications between client and server, don't know the
    software or hardware running and RATs helps. For some of the use
    cases, it's to allow programs to establish a secure channel
    between two peers which is also the promise of confidential
    computing.

  • Laurence: attestation of the client was the initial motivation
    for the RATs work, scoped to user devices. There are a bunch of
    use cases that are interesting, maybe engage with the browser
    vendors?

  • Paul W: I understand the proponents want to allow for peer or
    mutual peer attestation is in scope

  • Usama: yes
  • Yaron: we need to be very clear in the charter about this
    because there are important privacy implications

  • Laurence: In EAT we looked at privacy angle and we have some
    solutions

  • Watson: admin permissions must be extremely narrow

  • Usama/Thomas: yes

  • Mark Novak: concerns:

    • scalability and others

  • Nancy: we are trying to understand whether there is a problem to
    address

Open MIC discussion

BOF questions

Chairs Poll 1:

Raise your hand if you believe this problem is well defined enough for
the IETF to consider solving? Don't raise your hand if the problem
isn't well defined.

51 Yes
10 No
16 No opinion

Chairs Poll 2:

Raise your hand if you feel this problem is solvable, or don't raise
your hand if you believe this problem isn't solvable.

53 Yes
2 No
21 No opinion

Chairs Poll 3:

Who is willing to work on the problem?

28 Yes
14 No
20 No opinion

Dave Thaler (chat): A statement from CCC about the companies
[interested] would indeed be useful

Charter and Scope discussion

• Background and motivation

  • Why Authentication in Remote Attestation matters (Henk):
    • https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/
    • https://datatracker.ietf.org/liaison/1897/

• Ben Schwartz:

• there is not agreement about whether it's post-TLS yet, and the
  charter should say it's going to tie to TLS

  • specificall ydon't say "post handshake exchange"

• Ben: support existing pre-standard technologies where possible

  • "the wg will prefer pre-existing solutions where possible"

• EKR: key resrictions are no change to TLS and to use post-handshake

• Watson: architectural uestions about how does the evidence you get
  relate to the properties you want to attest. You could end up with a
  result that doesn't get what you need.
• Wes: can you send text to the list to that purpose
• JH: the charter should say that the RA session is bound to the TLS
  session
• SF: charter should clearly state that the work should be killed with
  fire if we see it's doing crappy job regarding to privacy
• EKR (chat): should say "after handshake completion" because
  "post-handshake" is a technical term in TLS
• Mike (chat): suggest that the the WG strike a Design Team with good
  representation from the WG ()
• Britta: scope request: be clear about what / if is authenticated
• Henk:
• Daniel: I like the current text. Echoing Jonathan's comment on
  binding properties. Also, there is a whole industry that is eager to
  consume a standardised solution to this problem (ETSI, 3GPP)
• ?: binding this to TLS is not a good idea.
• Usama: I disagree with the previous gentleman
• Uri: while still on the fence, I like the idea of binding it to the
  TLS
• Dave T: "per-session" freshness needs to be cleaned up
• EKR: also s/session/connection/
• Dave (chat) proposes: "The protocol must allow a Relying Party to
  ensure that Attestation Results is fresh, even during the lifetime
  of a TLS session"
• Henk (chat): I am confused by your "s/session/connection/" request
• Dave (chat): +1 to listing CCC in the "Dependencies and Liaisons"