[{"author": "Nancy Cam-Winget", "text": "

Hello EXPAT participants, we are starting now

", "time": "2025-07-21T12:30:46Z"}, {"author": "Eric Rescorla", "text": "

Well technically the purpose of this BOF is to determine whether we should form a WG.

", "time": "2025-07-21T12:33:00Z"}, {"author": "Eric Rescorla", "text": "

I don't think it's so much conveyed but rather bound to the TLS session

", "time": "2025-07-21T12:35:46Z"}, {"author": "Eric Rescorla", "text": "

I.e., to allow you to establish that a TLS session is actually a channel to the attested-to application

", "time": "2025-07-21T12:36:15Z"}, {"author": "Jonathan Hoyland", "text": "

IIUC it guarantees the TLS client shares secrets with the attester.

", "time": "2025-07-21T12:37:25Z"}, {"author": "Eric Rescorla", "text": "

Jonathan, you need a lot more than that. For instance, if you share the secret with some third party, that is obviously bad.

", "time": "2025-07-21T12:39:29Z"}, {"author": "Eric Rescorla", "text": "

But yes, part of the problem here is actually defining the property you want

", "time": "2025-07-21T12:40:03Z"}, {"author": "Robert Moskowitz", "text": "

So CA contain a Level Of Assurance Policy OID to address this. It is part of ICAO work in the forth-coming CP ICAO doc 10169. I include this LOA oid arc in draft-moskowitz-drip-dki

", "time": "2025-07-21T12:40:26Z"}, {"author": "Jonathan Hoyland", "text": "

Yeah, I was trying to describe the property I think you get, but not necessarily the one you want.

", "time": "2025-07-21T12:40:31Z"}, {"author": "Robert Moskowitz", "text": "

Some CA...

", "time": "2025-07-21T12:40:39Z"}, {"author": "Robert Moskowitz", "text": "

Of course a policy oid only says what members are suppose to do, not necessarily what they really do..,. ;)

", "time": "2025-07-21T12:42:26Z"}, {"author": "Muhammad Sardar", "text": "

Properties that we are thinking about (in addition to standard TLS properties) are:

\n
    \n
  1. per-session evidence freshness
    2. \n
  2. Evidence is bound to TLS session (i.e., it cannot be reused in any other session)
    3. \n
", "time": "2025-07-21T12:42:33Z"}, {"author": "Eric Rescorla", "text": "

Well, both of these are narrow technical properties. But they are ways to achieve some higher-level security goal.

", "time": "2025-07-21T12:43:57Z"}, {"author": "Stephen Farrell", "text": "

on the previous slide (3) was relying party the TLS client ?

", "time": "2025-07-21T12:43:59Z"}, {"author": "Watson Ladd", "text": "

Robert, not sure I see it in draft-moskowitz-drip-dki-09, but it's early and i haven't caffinated sufficiently yet

", "time": "2025-07-21T12:44:02Z"}, {"author": "Eric Rescorla", "text": "

Which is about the channel

", "time": "2025-07-21T12:44:02Z"}, {"author": "Robert Moskowitz", "text": "

@Watson, OOPs that is draft-ietf-drip-dki!

", "time": "2025-07-21T12:45:01Z"}, {"author": "Muhammad Sardar", "text": "

Eric Rescorla said:

\n
\n

Well, both of these are narrow technical properties. But they are ways to achieve some higher-level security goal.

\n
\n

Surely, there will be other properties in addition to these, derived from security goals.

", "time": "2025-07-21T12:45:04Z"}, {"author": "Muhammad Sardar", "text": "

Stephen Farrell said:

\n
\n

on the previous slide (3) was relying party the TLS client ?

\n
\n

yes, if Server is Attester. Can be the other way around.

", "time": "2025-07-21T12:45:32Z"}, {"author": "Eric Rescorla", "text": "

Well, the point I am making is that we need to start by looking at what we are trying to achieve, not by defining these technical properties

", "time": "2025-07-21T12:45:52Z"}, {"author": "Eric Rescorla", "text": "

Because a lot of the problem here is the gap between those two

", "time": "2025-07-21T12:46:08Z"}, {"author": "Muhammad Sardar", "text": "

i.e., if TLS Server is Attester, then TLS Client is RP.
\nIf TLS Client is Attester, then TLS Server is RP.

", "time": "2025-07-21T12:46:14Z"}, {"author": "Muhammad Sardar", "text": "

There can be mutual attestaion as well (combination of both).

", "time": "2025-07-21T12:46:45Z"}, {"author": "Uri Blumenthal", "text": "

Are you familiar with KeyLime design and product?

", "time": "2025-07-21T12:48:16Z"}, {"author": "Uri Blumenthal", "text": "

https://keylime.readthedocs.io/en/latest/

", "time": "2025-07-21T12:48:28Z"}, {"author": "Muhammad Sardar", "text": "

Eric Rescorla said:

\n
\n

Well, the point I am making is that we need to start by looking at what we are trying to achieve, not by defining these technical properties

\n
\n

High level goal is to ensure that the identity and attestation is of the same entity (and not relayed to someone else).

", "time": "2025-07-21T12:48:58Z"}, {"author": "Eric Rescorla", "text": "

Identity of what

", "time": "2025-07-21T12:49:27Z"}, {"author": "Jonathan Hoyland", "text": "

@Britta Hale, the way the EA RFC works is that the EA authenticates the TLS layer and the TLS layer authenticates the EA. So the guarantee you get is that as long as one of TLS or the EA is secure, the other is honest.

", "time": "2025-07-21T12:49:48Z"}, {"author": "Eric Rescorla", "text": "

I actually don't think it's going beyond clarification.

", "time": "2025-07-21T12:49:59Z"}, {"author": "Muhammad Sardar", "text": "

Eric Rescorla said:

\n
\n

Identity of what

\n
\n

Identity of peer (Subject Alternative Name)

", "time": "2025-07-21T12:50:33Z"}, {"author": "Eric Rescorla", "text": "

But again, if it's not bound to the channel, it's useless

", "time": "2025-07-21T12:50:48Z"}, {"author": "Muhammad Sardar", "text": "

Eric Rescorla said:

\n
\n

But again, if it's not bound to the channel, it's useless

\n
\n

I may be misunderstanding something. But if Certificate-based authentication is done, then we know what SAN is the peer talking to. TLS remains unchanged and should ensure that authentication holds. Am I missing something here?

", "time": "2025-07-21T12:52:34Z"}, {"author": "Uri Blumenthal", "text": "

Host properties may change. I.e., it c can get compromise between the time its attenuation record was sent and now.

", "time": "2025-07-21T12:55:06Z"}, {"author": "Britta Hale", "text": "

@Jonathan: that is my point: there is a lack of clarity on the goals here (and potentially a risk of looking at this as a catch-all for fixing problems on either side, which will invariably result in achieving neither). The goal should be made very clear of which problem is being attempted to be solved.

", "time": "2025-07-21T12:55:40Z"}, {"author": "Eric Rescorla", "text": "
\n

TLS remains unchanged and should ensure that authentication holds.

\n
\n

Well, unless, as I keep pointing out, the keys leak. Or the system provides an input/output oracle

", "time": "2025-07-21T12:55:57Z"}, {"author": "Watson Ladd", "text": "

@Uri The measurements we have don't actually detect this, or they are too fine to interpret. Or both at the same time

", "time": "2025-07-21T12:56:04Z"}, {"author": "Muhammad Sardar", "text": "

Uri Blumenthal said:

\n
\n

Host properties may change. I.e., it c can get compromise between the time its attenuation record was sent and now.

\n
\n

Sure, that's why we have post-handshake attestation. You can do it at any frequency you want (each day, each hour etc.) Send an Authenticator Request and get a Authenticator back.

", "time": "2025-07-21T12:56:08Z"}, {"author": "Jonathan Hoyland", "text": "

@Muhammad I'm not sure that gives you the property I think you want.

", "time": "2025-07-21T12:57:20Z"}, {"author": "Uri Blumenthal", "text": "

But that\u2019s not a TLS-level problem - it\u2019s a host-level problem.

", "time": "2025-07-21T12:57:35Z"}, {"author": "Jonathan Hoyland", "text": "

Sending multiple authenticators on a single channel doesn't provide compound authentication between the EAs.

", "time": "2025-07-21T12:57:58Z"}, {"author": "Muhammad Sardar", "text": "

Jonathan Hoyland said:

\n
\n

@Muhammad I'm not sure that gives you the property I think you want.

\n
\n

You are right. Authenticator by default does not. But we extend the Authenticator's Certificate message with attestation evidence.

", "time": "2025-07-21T12:58:16Z"}, {"author": "Jonathan Hoyland", "text": "

You know that the signer of EA_1 shares secrets with the TLS peer, and that the signer of EA_2 shares secrets with the TLS peer, but not that the signer of EA_1 shares secrets with the signer of EA_2.

", "time": "2025-07-21T12:59:06Z"}, {"author": "Muhammad Sardar", "text": "

Jonathan Hoyland said:

\n
\n

Sending multiple authenticators on a single channel doesn't provide compound authentication between the EAs.

\n
\n

We don't need that. We just need a newer Evidence with potentially change of state of machine (firmware update for example).

", "time": "2025-07-21T12:59:18Z"}, {"author": "Watson Ladd", "text": "

If we're saying this solution has properties that can't actually be delivered, or require very stringent protections at one end that when we write them down in security considerations scare people off, what's the point?

", "time": "2025-07-21T12:59:48Z"}, {"author": "Muhammad Sardar", "text": "

But perhaps that is a discussion on the solution, not on the problem itself.

", "time": "2025-07-21T12:59:50Z"}, {"author": "Henk Birkholz", "text": "

Uri Blumenthal:

\n
\n

Are you familiar with KeyLime design and product?
\nhttps://keylime.readthedocs.io/en/latest/

\n
\n

Yes, both RATS WG in IETF as well as TCG WGs interact with KeyLime

", "time": "2025-07-21T12:59:51Z"}, {"author": "Thom Wiggers", "text": "
\n

require very stringent protections at one end that when we write them down in security considerations scare people off

\n
\n

This seems to be the nature of developing software for CC environments though, e.g. look at how much effort Signal needed to put in for ORAM https://signal.org/blog/private-contact-discovery/

", "time": "2025-07-21T13:01:15Z"}, {"author": "Jonathan Hoyland", "text": "

@Muhammad do you not need to know that the attester that signed the first EA is the same attester that signed the second EA?

", "time": "2025-07-21T13:02:12Z"}, {"author": "Thom Wiggers", "text": "

There is probably a space for solving some of this but I don't think this is ever going to be a \"general purpose\" thing anyway because doing this kind of compute is just very difficult and expert-level

", "time": "2025-07-21T13:02:17Z"}, {"author": "Thom Wiggers", "text": "

(even if the channel-establishment-protocol ends up being off-the-shelf)

", "time": "2025-07-21T13:02:54Z"}, {"author": "Mike Ounsworth", "text": "

Watson Ladd said:

\n
\n

If we're saying this solution has properties that can't actually be delivered, or require very stringent protections at one end that when we write them down in security considerations scare people off, what's the point?

\n
\n

Yeah, that's a signal in-and-of-itself, eh?

", "time": "2025-07-21T13:03:22Z"}, {"author": "Hannes Tschofenig", "text": "

@Thom: It is not meant to be a general purpose solution. There are certain use cases where this approach makes sense.

", "time": "2025-07-21T13:06:16Z"}, {"author": "Ionu\u021b Mihalcea", "text": "

@Jonathan - the attestation evidence comes with identifiers that can be tracked between EAs

", "time": "2025-07-21T13:06:32Z"}, {"author": "Eliot Lear", "text": "

You know when a presentation has meat when this group gets quiet. ;-)

", "time": "2025-07-21T13:06:54Z"}, {"author": "Jonathan Hoyland", "text": "

@Ionu\u0163 Ah, so there's a dependency on the security of the attested data. Modelling that sounds really hairy.

", "time": "2025-07-21T13:08:00Z"}, {"author": "Thom Wiggers", "text": "

@Hannes Tschofenig I understand, I was just pushing back on \"if we need to provide many caveats, is this worth doing\"

", "time": "2025-07-21T13:09:35Z"}, {"author": "Eric Rescorla", "text": "

Does anyone actually do software upgrades without tearing down the TLS connection?

", "time": "2025-07-21T13:10:24Z"}, {"author": "Eric Rescorla", "text": "

I mean normally

", "time": "2025-07-21T13:10:28Z"}, {"author": "Henk Birkholz", "text": "

Live firmware updates exist

", "time": "2025-07-21T13:10:28Z"}, {"author": "Watson Ladd", "text": "

but the new firmware starts running?

", "time": "2025-07-21T13:10:39Z"}, {"author": "Henk Birkholz", "text": "

Life microcode updates exist...

", "time": "2025-07-21T13:10:40Z"}, {"author": "Henk Birkholz", "text": "

it is seemless

", "time": "2025-07-21T13:10:48Z"}, {"author": "Hannes Tschofenig", "text": "

I believe it is worth doing work even if not everyone on the planet needs it.

", "time": "2025-07-21T13:10:57Z"}, {"author": "Henk Birkholz", "text": "

also microcode updates are can be seemless today

", "time": "2025-07-21T13:11:02Z"}, {"author": "Benjamin Schwartz", "text": "

I assumed the timeliness thing was to support a form of revocation.

", "time": "2025-07-21T13:11:14Z"}, {"author": "Giridhar Mandyam", "text": "

Re: ekr, \"if it's not bound to the channel\". An attested protocol that binds to the channel was already attempted with FIDO (tokenbinding in https://www.w3.org/TR/webauthn-2/#dictdef-collectedclientdata), but the attestation and TLS token binding were not tied together. In my opinion, if the IETF had defined attested TLS token binding then the attestation would have been bound to the TLS connection - see https://datatracker.ietf.org/doc/draft-mandyam-tokbind-attest/. I also think that the WG charter that was circulated would allow such an effort (with a different starting point than my draft for tokbind because Token Binding is no longer being supported by implementors).

", "time": "2025-07-21T13:11:27Z"}, {"author": "Henk Birkholz", "text": "

timeliness (freshness) is important, if you want to increase the chance that evidence actually still reflects reality.

", "time": "2025-07-21T13:12:04Z"}, {"author": "Dave Thaler", "text": "

even if life updates exist, there's some time window between the update and when the peer can possibly notice (how often do you check was my question... life of the TLS connection or more frequently). The existence of a time window means your attestation doesn't reflect reality and you may be making incorrect security decisions.

", "time": "2025-07-21T13:12:06Z"}, {"author": "Henk Birkholz", "text": "

@Dave: get out of my head

", "time": "2025-07-21T13:12:29Z"}, {"author": "Uri Blumenthal", "text": "

Why not simply request and acquire alteration records from within a TLS channel? Without having to bother changing TLS?

", "time": "2025-07-21T13:12:32Z"}, {"author": "Jonathan Hoyland", "text": "

@Uri because if you don't bind to the TLS channel you can't detect TLS terminating proxies

", "time": "2025-07-21T13:13:16Z"}, {"author": "Uri Blumenthal", "text": "

^ attestation (thanks, spellchecker)

", "time": "2025-07-21T13:13:28Z"}, {"author": "Jonathan Hoyland", "text": "

(The EA proposal also doesn't change TLS, it is an RFC overlay)

", "time": "2025-07-21T13:13:42Z"}, {"author": "Uri Blumenthal", "text": "

Why do you care about proxies? Given that attestation is end-bound?

", "time": "2025-07-21T13:14:26Z"}, {"author": "Hannes Tschofenig", "text": "
\n

Without having to bother changing TLS?

\n
\n

The proposed solution does not change TLS

", "time": "2025-07-21T13:14:46Z"}, {"author": "Thom Wiggers", "text": "

I'm not clear if the intent here is to set up an end-to-end _confidential_ connection

", "time": "2025-07-21T13:15:03Z"}, {"author": "Watson Ladd", "text": "

if the attestation signs an exporter relayed from a different server, none of the properties you looked at in the endpoint apply to where the data is going

", "time": "2025-07-21T13:15:20Z"}, {"author": "Thom Wiggers", "text": "

end-to-end authenticated seems to be a goal

", "time": "2025-07-21T13:15:20Z"}, {"author": "Watson Ladd", "text": "

that's at least implied to be impossible in a few of the usages

", "time": "2025-07-21T13:15:31Z"}, {"author": "Hannes Tschofenig", "text": "

For confidential computing you need an e2e confidential connection.

", "time": "2025-07-21T13:15:51Z"}, {"author": "Thomas Hardjono", "text": "

end-to-end complete-stack atetstation based on HW RoT

", "time": "2025-07-21T13:16:11Z"}, {"author": "Hannes Tschofenig", "text": "

The attestation evidence does not need to be confidential e2e from the attester to the verifier.

", "time": "2025-07-21T13:16:30Z"}, {"author": "Robert Moskowitz", "text": "

There is a song going through my head about it being too late...

", "time": "2025-07-21T13:16:34Z"}, {"author": "Jonathan Hoyland", "text": "

@Uri you want to be able to detect someone adding a proxy, i.e. you want to be sure that you are talking to the device that has the secrets.

", "time": "2025-07-21T13:16:57Z"}, {"author": "Thom Wiggers", "text": "

so why not just run a noise protocol End-to-End :thinking: What is TLS doing here?

", "time": "2025-07-21T13:17:19Z"}, {"author": "Kathleen Moriarty", "text": "

Does Usama need EKR's question in writing to fully hear/understand the question? Usama has been handling his questions well, so I am wondering if that would help.

", "time": "2025-07-21T13:17:45Z"}, {"author": "Dave Thaler", "text": "

DICE does provide what EKR is saying. If you don't use something like that, then EKR's problem exists.

", "time": "2025-07-21T13:18:20Z"}, {"author": "Thomas Hardjono", "text": "

Yes, DICE does this.

", "time": "2025-07-21T13:18:42Z"}, {"author": "Watson Ladd", "text": "

this DICE? https://datatracker.ietf.org/wg/dice/charter/

", "time": "2025-07-21T13:18:44Z"}, {"author": "Dave Thaler", "text": "

no

", "time": "2025-07-21T13:18:56Z"}, {"author": "Kathleen Moriarty", "text": "

No, TCG's DICE

", "time": "2025-07-21T13:18:57Z"}, {"author": "Dave Thaler", "text": "

different dice...

", "time": "2025-07-21T13:19:01Z"}, {"author": "Thom Wiggers", "text": "

https://trustedcomputinggroup.org/what-is-a-device-identifier-composition-engine-dice/

", "time": "2025-07-21T13:19:06Z"}, {"author": "Robert Moskowitz", "text": "

This seems an unsolvable problem. At some point, in some cases, things break and the app does not know.

", "time": "2025-07-21T13:19:10Z"}, {"author": "Watson Ladd", "text": "

thanks! strategic acronyme shortage

", "time": "2025-07-21T13:19:15Z"}, {"author": "Dave Thaler", "text": "

https://trustedcomputinggroup.org/work-groups/dice-architectures/

", "time": "2025-07-21T13:19:20Z"}, {"author": "Giridhar Mandyam", "text": "

I don't think DICE solves the problem of a TCB changing at runtime. Isn't ekr's question more relevant to such a scenario?

", "time": "2025-07-21T13:19:44Z"}, {"author": "Giridhar Mandyam", "text": "

\"TCB changing\" by a hostile party

", "time": "2025-07-21T13:20:12Z"}, {"author": "Henk Birkholz", "text": "

+1 Dave
\n(but I think ekr does not look at the chat, rn :sweat_smile:)

", "time": "2025-07-21T13:20:12Z"}, {"author": "Dave Thaler", "text": "

I don't believe it's an unsolvable problem. It may be that current implementations don't solve it, but I don't believe it's inherently unsolvable.

", "time": "2025-07-21T13:20:13Z"}, {"author": "Eric Rescorla", "text": "

Not while I'm talking but I am now

", "time": "2025-07-21T13:20:26Z"}, {"author": "Watson Ladd", "text": "

There's a reason we call the world ideal world when we have trusted third parties

", "time": "2025-07-21T13:20:41Z"}, {"author": "Dave Thaler", "text": "

EKR please mute

", "time": "2025-07-21T13:20:45Z"}, {"author": "Eric Rescorla", "text": "

To be clear, I think this problem is readily fixable by having part of the promise be \"the firmware can't change\".

", "time": "2025-07-21T13:21:05Z"}, {"author": "Eric Rescorla", "text": "

But I just think that that also limits the analysis

", "time": "2025-07-21T13:21:31Z"}, {"author": "Dave Thaler", "text": "

@ekr or: if the firmware changes, the key changes and the old key is not usable any more.

", "time": "2025-07-21T13:21:33Z"}, {"author": "Dave Thaler", "text": "

either way \"the firmware can't change during the lifetime of the key\" is a good phrasing in my view.

", "time": "2025-07-21T13:22:04Z"}, {"author": "Ionu\u021b Mihalcea", "text": "

@Eric - part of the attestation evidence produced by the RoT indicates whether the firmware can be changed via live firmware update. it's up to the relying party to accept that (or not)

", "time": "2025-07-21T13:22:04Z"}, {"author": "Eric Rescorla", "text": "

@Dave: exactly!

", "time": "2025-07-21T13:22:04Z"}, {"author": "Thom Wiggers", "text": "

Presumably the attestation is some form of \"I am firmware with hash xyz\". The relying party should probably know if that firmware version allows itself to be updated?

", "time": "2025-07-21T13:22:06Z"}, {"author": "Paul Wouters", "text": "

I think ekr means more: if you want to update the firware, you must 1) disconnect all clients. 2) wipe all application data. 3) startup with a clean state. 4) accept new attstation/clients

", "time": "2025-07-21T13:22:18Z"}, {"author": "Eric Rescorla", "text": "

@Paul: yes, exactly. If you allow someone to upload untrusted firmware, you need what's effectively a memory barrier

", "time": "2025-07-21T13:22:42Z"}, {"author": "Paul Wouters", "text": "

(at 2.5 update the firmware)

", "time": "2025-07-21T13:22:47Z"}, {"author": "Henk Birkholz", "text": "

If initially (I wanna say at the beginning of the TLS session), the evidence provided \"convinces\" you that the Attester's TCB is fine, and update mechanisms are in that TCB, then you will get updated Evidence via the session when the TCB grows (SUIT manifests & SUIT Reports can do that, for example). And you can trust in the trustworthiness of that update process and in consequence future Evidence produced by the Attester

", "time": "2025-07-21T13:23:10Z"}, {"author": "Steve Hill", "text": "

If the firmware changes you need to tear down the TLS session to force re-attestation before new data is sent

", "time": "2025-07-21T13:23:11Z"}, {"author": "Giridhar Mandyam", "text": "

Why do we need such a promise? The attester can push an attestation upon detecting a FW changel. TLS endpoints can choose to terminate the connection or continuing when receiving a push attestation.

", "time": "2025-07-21T13:23:27Z"}, {"author": "Eliot Lear", "text": "

Why are we assuming that this is always firmware?

", "time": "2025-07-21T13:23:37Z"}, {"author": "Eliot Lear", "text": "

What if there is an asynchronous change?

", "time": "2025-07-21T13:23:59Z"}, {"author": "Dave Thaler", "text": "

in practice I think what DICE does in practice (correct me if I'm wrong) is that it can ensure that the firmware can only be changed by someone who authorized the old firmware. That means it can only be changed by someone who could have already changed the app state, not a new attacker.

", "time": "2025-07-21T13:24:01Z"}, {"author": "Henk Birkholz", "text": "

@Eliot (about firmware or not firmware):
\nIf it is some software in some target environment, you already trust the Attester's TCB to provide you with appropriate fresh evidence.

", "time": "2025-07-21T13:24:58Z"}, {"author": "Eric Rescorla", "text": "

@Giridhar: because the concern is that the peer surreptitiously changes the firmware

", "time": "2025-07-21T13:25:01Z"}, {"author": "Thom Wiggers", "text": "

@Dave Thaler to some extent, I may be not entirely trusting the person deploying to the enclave. See e.g. the Signal use case where I don't trust Signal, I trust the publicly published source code

", "time": "2025-07-21T13:25:01Z"}, {"author": "Kathleen Moriarty", "text": "

@Eliot, I think the firmware is easier since attestation at boot of firmware is common now.

", "time": "2025-07-21T13:25:37Z"}, {"author": "Eric Rescorla", "text": "

Anyway, I don't think any of this is fatal to the effort; it's just a matter of scoping what this can and cannot achieve.

", "time": "2025-07-21T13:26:05Z"}, {"author": "Eric Rescorla", "text": "

And in fact, I think once you've done that, the problem becomes easier because you don't need to worry about unexpected firmware changes

", "time": "2025-07-21T13:26:34Z"}, {"author": "Eliot Lear", "text": "

@Hank, that's really my point: the attestation is only ever valid at a point in time. Nobody can guarantee a teardown in case of compromise. The best you can do is force some form of re-attestation from time to time.

", "time": "2025-07-21T13:26:35Z"}, {"author": "Eric Rescorla", "text": "

@Eliot: no, that's not correct. For instance, the confidential computing platform could guarantee that any changes to the firmware involve zeroing the memory

", "time": "2025-07-21T13:27:08Z"}, {"author": "Benjamin Schwartz", "text": "

It sounds like the scenario is: (1) Attestation to TCB v5.0, (2) the vendor rolls out TCB v5.1, (3) attestation to v5.1, (4) a vulnerability is published in v5.0. As a client, I want to be able to look back in time and see that I checked the upgrade before the vulnerability was published.

", "time": "2025-07-21T13:27:26Z"}, {"author": "Robert Moskowitz", "text": "

should IPsec also provide this functionality?

", "time": "2025-07-21T13:27:31Z"}, {"author": "Eliot Lear", "text": "

@ekr or so you hope, right?

", "time": "2025-07-21T13:27:45Z"}, {"author": "Eric Rescorla", "text": "

@Eliot: yes, so you hope, but all of this stuff is hope-based

", "time": "2025-07-21T13:28:02Z"}, {"author": "Kathleen Moriarty", "text": "

@Robert, I think IPsec, EDHOC are on their list after tLS

", "time": "2025-07-21T13:28:04Z"}, {"author": "Eliot Lear", "text": "

Right so to me there is always a window of vulnerability

", "time": "2025-07-21T13:28:23Z"}, {"author": "Henk Birkholz", "text": "

if the Atterster's TCB works as you expect (and I assuming fresh Evidence is generated at any relavant change of Attester) then - as soon as Evidence appraisal fails, termination of session can be absolutely be the result.

", "time": "2025-07-21T13:28:27Z"}, {"author": "Eliot Lear", "text": "

or at least a window of risk of vulnerability

", "time": "2025-07-21T13:28:42Z"}, {"author": "Eric Rescorla", "text": "

@Eliot: well are we assuming the enclaves are secure (which, you know, they're actually kind of not) or that they are not

", "time": "2025-07-21T13:28:52Z"}, {"author": "Thom Wiggers", "text": "

\"hope-based\" I think is a bit unfair, the people implementing this will have to and should be making explicit choices about what kind of environment they're setting up. Part of that should be figuring out what they need from the platform.

", "time": "2025-07-21T13:29:07Z"}, {"author": "Eric Rescorla", "text": "

If they are secure, then you can enforce zeroization. If they are not secure, then all bets are off

", "time": "2025-07-21T13:29:07Z"}, {"author": "Henk Birkholz", "text": "

Timely observability of Attester changes is key here. The same way it is implemented in Cisco routers via YANG Push that you trust because it is part of the TCB.

", "time": "2025-07-21T13:29:24Z"}, {"author": "Uri Blumenthal", "text": "

Some use cases do NOT want end-points to reveal their \u201cattestation records\u201d. So, it must not be a standard part of TLS or IPsec. It\u2019s an option that SOME use cases require, and others abhor.

", "time": "2025-07-21T13:29:55Z"}, {"author": "Eric Rescorla", "text": "

It's simply not enough to have notification of attester changes, because if you can load arbitrary new code and then attest and that code has access to the keys, then the code can just exfiltrate the keys

", "time": "2025-07-21T13:30:24Z"}, {"author": "Hannes Tschofenig", "text": "

There are ways to encrypt attestation evidence but so far I have not seen this in practice

", "time": "2025-07-21T13:30:27Z"}, {"author": "Eric Rescorla", "text": "

(and even if the TCB would emit an update, you can just disconnect the network first)

", "time": "2025-07-21T13:31:13Z"}, {"author": "Hannes Tschofenig", "text": "

On the security of platforms: of course, you have to rely on the work by chip manufacturers. This trust in their work may not always be justified and there is certainly room for improvement.

", "time": "2025-07-21T13:31:29Z"}, {"author": "Eliot Lear", "text": "

If we assume that the system is secure through attestation at time T, the issue I am zooming in on is whether the peer can be compromised thereafter prior to the next attestation. Which I think was your point, right?

", "time": "2025-07-21T13:31:39Z"}, {"author": "Henk Birkholz", "text": "

@Hannes, it is rare today and sometimes found in critical infrastructure. But we have, for example, not pushed SD-EAT (that would have an encryption feature) yet.

", "time": "2025-07-21T13:31:39Z"}, {"author": "Eric Rescorla", "text": "

@Hannes, I mean it's not like we know nothing about the security of these systems. There is a whole literature on breaking the commercial TCBs

", "time": "2025-07-21T13:32:16Z"}, {"author": "Benjamin Schwartz", "text": "

@Eric Rescorla I believe there is a foundational assumption here that the conditions for firmware replacement are themselves part of the TCB, and typically include \"must be signed by the publisher of the current TCB\". Trusting the TCB includes understanding and trusting those update rules.

\n

I still think this is worrying, as it increases the ability of the publisher to introduce backdoors, but it's not obviously insecure.

", "time": "2025-07-21T13:32:28Z"}, {"author": "Mike Ounsworth", "text": "

I personally am excited about this work in the context of enterprise; for example a TLS-VPN where you can't come on the network unless you're running the corp-issued hardware in its stock configuration. \"Prove that you're in a sane state\" is a thing that, for example, PKI client-auth can't do. But I recognize that there's ALL SORTS of privacy implications buried there.

", "time": "2025-07-21T13:32:30Z"}, {"author": "Stephen Farrell", "text": "

it client attestation comes with potential privacy problems (as seems the case) and if the putative wG defines how to do client attestation, then what's to stop any mobile app using the WG's output to create the privacy problem?

", "time": "2025-07-21T13:32:38Z"}, {"author": "Hannes Tschofenig", "text": "

@Ekr. Sure. There have been issues but it is not that these players are not trying their best.

", "time": "2025-07-21T13:32:57Z"}, {"author": "Henk Birkholz", "text": "

@Eliot: as Claims Collection and Evidence generation takes (as small amount, but not zero) time, yes there is a time window (that can be rather really small) where the most recent Evidence becomes stale

", "time": "2025-07-21T13:33:04Z"}, {"author": "Eric Rescorla", "text": "

@Hannes: I'm sure they're trying, but it's not clear it's possible

", "time": "2025-07-21T13:33:12Z"}, {"author": "Paul Wouters", "text": "

stephen: cant they do that already by reqiring client TLS authentication with a privte CA? So having infrastructure does not mean webpki should implement it

", "time": "2025-07-21T13:33:33Z"}, {"author": "Dave Thaler", "text": "

@Benjamin yes

", "time": "2025-07-21T13:33:37Z"}, {"author": "Hannes Tschofenig", "text": "

@Ekr: You seem to be think that this is practically impossible. I think that there is benefit - even though it is not perfect.

", "time": "2025-07-21T13:33:56Z"}, {"author": "Henk Birkholz", "text": "

The \"Below Zero Trust\" approach as described in https://datatracker.ietf.org/doc/draft-ietf-rats-ar4si/ can mitigate that timing issue mostly.

", "time": "2025-07-21T13:33:57Z"}, {"author": "Monty Wiseman", "text": "

Privacy should be a policy decision. If I'm working at a bank, my transactions must be traceable. The protocol should be agnostic to policy.

", "time": "2025-07-21T13:34:15Z"}, {"author": "Stephen Farrell", "text": "

@paul: I was reacting to the idea a charter could thread-the-needle on the privacy problem

", "time": "2025-07-21T13:34:16Z"}, {"author": "Henk Birkholz", "text": "

But as there is also latency due to using the Internet, this micro windows of unobservability always exist

", "time": "2025-07-21T13:34:36Z"}, {"author": "Eric Rescorla", "text": "

I think part of the problem is that there are two threat models: (1) this is my own client and my own workload and only I need to trust it (2) this is my workload but other people are entrusting their data to it (as in DAP) and they need to trust it

", "time": "2025-07-21T13:34:40Z"}, {"author": "Kathleen Moriarty", "text": "

@Hannes, yes, sometime we take steps toward improvement where perfect is just too difficult.

", "time": "2025-07-21T13:34:44Z"}, {"author": "Eric Rescorla", "text": "

And in case (2) it's not sufficient to just have the author of the app trusted, which is back to Ben's point

", "time": "2025-07-21T13:35:06Z"}, {"author": "Eric Rescorla", "text": "

In case (1) it might be

", "time": "2025-07-21T13:35:19Z"}, {"author": "Henk Birkholz", "text": "

your cert could expire a millisecond ather authentication success (I am exaggerating here, there can be safeguards against that).

", "time": "2025-07-21T13:35:36Z"}, {"author": "Monty Wiseman", "text": "

Seem we are conflating the Charter discussion with the protocol discussion -- we are too far into the solution space.

", "time": "2025-07-21T13:36:06Z"}, {"author": "Stuart Card", "text": "

+1 @Monty Wiseman

", "time": "2025-07-21T13:36:30Z"}, {"author": "Hannes Tschofenig", "text": "

+1 Monty

", "time": "2025-07-21T13:36:38Z"}, {"author": "Ionu\u021b Mihalcea", "text": "

@Monty +1

", "time": "2025-07-21T13:36:41Z"}, {"author": "Henk Birkholz", "text": "

@Monty: yeah, not wrong, but the basic principles of freshness should be understood

", "time": "2025-07-21T13:36:42Z"}, {"author": "Monty Wiseman", "text": "

@henk Why?

", "time": "2025-07-21T13:37:00Z"}, {"author": "Henk Birkholz", "text": "

Because you could attempt intra-hanshake and modify some part of TLS and be done

", "time": "2025-07-21T13:37:33Z"}, {"author": "Benjamin Schwartz", "text": "

Eric Rescorla said:

\n
\n

And in case (2) it's not sufficient to just have the author of the app trusted, which is back to Ben's point

\n
\n

Yes, but the client might trust Intel, and want mid-connection Intel firmware updates, even if it doesn't trust the service operator to modify its binary without fresh manual review.

", "time": "2025-07-21T13:37:34Z"}, {"author": "Henk Birkholz", "text": "

that is not a good idea

", "time": "2025-07-21T13:37:37Z"}, {"author": "Jonathan Hoyland", "text": "

Why doesn't this work perfectly well with SPIFFE?

", "time": "2025-07-21T13:37:38Z"}, {"author": "Jonathan Hoyland", "text": "

SPIFFE allows x.509 certs, and TLS EAs support x.509 certs.

", "time": "2025-07-21T13:37:57Z"}, {"author": "Eric Rescorla", "text": "

@Benjamin, yes, I agree with that. In fact, you better trust Intel because they're the ones guaranteeing the whole thing

", "time": "2025-07-21T13:38:03Z"}, {"author": "Hannes Tschofenig", "text": "

@Jonathan: This work is 100% applicable to SPIFFEE

", "time": "2025-07-21T13:38:19Z"}, {"author": "Dave Thaler", "text": "

If you care about preventing mid-connection firmware (or other TCB component) updates, and I think folks should care, then I think that can be an appraisal policy that can be done.

", "time": "2025-07-21T13:38:38Z"}, {"author": "Henk Birkholz", "text": "

+1 Dave

", "time": "2025-07-21T13:38:53Z"}, {"author": "Eric Rescorla", "text": "

@Dave: I agree! But I think if we think about it properly, it may make the solution simpler, which is why I mentioned it!

", "time": "2025-07-21T13:39:28Z"}, {"author": "Benjamin Schwartz", "text": "

The design question to me is whether we really need TLS connections to survive across TCB updates from Intel, Microsoft, AWS, etc. Do they really happen often enough for this to matter?

", "time": "2025-07-21T13:39:38Z"}, {"author": "Mike Ounsworth", "text": "

My vote on the charter question is that there is a valuable, solvable problem here, but the charter is going to need to do some AGGRESSIVE scoping.

", "time": "2025-07-21T13:41:04Z"}, {"author": "Eric Rescorla", "text": "

@Benjamin: right I think if we just banned that this would become a lot easier to reason abot

", "time": "2025-07-21T13:41:08Z"}, {"author": "Jonathan Hoyland", "text": "

I think the problem is well defined, but there are a _lot_ of dragons.

", "time": "2025-07-21T13:41:10Z"}, {"author": "Watson Ladd", "text": "

surely if you aren't sure if the question is well defined it isn't well defined

", "time": "2025-07-21T13:41:29Z"}, {"author": "Thom Wiggers", "text": "

I don't think the problem/question are super _well_ defined but I think there's enough definition to work on it

", "time": "2025-07-21T13:41:55Z"}, {"author": "Laurence Lundblade", "text": "

+1 to Monty's comment about privacy being a policy problem

", "time": "2025-07-21T13:42:15Z"}, {"author": "Muhammad Sardar", "text": "

Jonathan Hoyland said:

\n
\n

I think the problem is well defined, but there are a _lot_ of dragons.

\n
\n

That's where we need your help and expertise, Jonathan.

", "time": "2025-07-21T13:42:56Z"}, {"author": "Muhammad Sardar", "text": "

The WG will keep RATS, TLS and UFMRG in the loop.

", "time": "2025-07-21T13:43:21Z"}, {"author": "Dave Thaler", "text": "

@Eric yes. Though I suspect there are customers out there who care about preventing live updates, and those who don't (but probably should :) either because a current provider doesn't support it and they don't have a choice, or because they don't know any better. What the IETF shoudl do about that, I'm not sure.

", "time": "2025-07-21T13:43:25Z"}, {"author": "Stephen Farrell", "text": "

\"solveable\" includes both \"nicely solveable\" and \"solveable with unacceptable side-effects\" (I think(

", "time": "2025-07-21T13:43:43Z"}, {"author": "Watson Ladd", "text": "

and \"solveable, but not as far as you need for your examples to work\"

", "time": "2025-07-21T13:43:57Z"}, {"author": "Uri Blumenthal", "text": "

@Stephen yes.

", "time": "2025-07-21T13:44:32Z"}, {"author": "Mike Ounsworth", "text": "

I think the next step is to bat around charter text and see if that converges or not.

", "time": "2025-07-21T13:44:55Z"}, {"author": "Dave Thaler", "text": "

e.g., would AWS do an IETF solution? Is AWS participating in the IETF?

", "time": "2025-07-21T13:45:25Z"}, {"author": "Benjamin Schwartz", "text": "

Speaking of dragons, the idea of trying to reason about the security guarantees of an enclave that has operated continuously through TCB updates seems like a real headache.

", "time": "2025-07-21T13:45:31Z"}, {"author": "Eric Rescorla", "text": "

Dave Thaler said:

\n
\n

e.g., would AWS do an IETF solution? Is AWS participating in the IETF?

\n
\n

Exactly. We are trying to avoid XKCD 927

", "time": "2025-07-21T13:45:44Z"}, {"author": "Dave Thaler", "text": "

I don't think this poll answers EKRs question

", "time": "2025-07-21T13:46:03Z"}, {"author": "Dave Thaler", "text": "

hence my \"no opinion\" since I have the same question

", "time": "2025-07-21T13:46:17Z"}, {"author": "Benjamin Schwartz", "text": "

Dave Thaler said:

\n
\n

e.g., would AWS do an IETF solution? Is AWS participating in the IETF?

\n
\n

Do we need cloud operators' participation? I assume that the TLS binary and all of this code is part of the application, provided by the customer, not by the cloud provider.

", "time": "2025-07-21T13:46:26Z"}, {"author": "Stephen Farrell", "text": "

they should change \"no opinion\" to \"disagree with question\" and it'd win every time:-)

", "time": "2025-07-21T13:46:54Z"}, {"author": "Uri Blumenthal", "text": "

How many companies would consider KeyLime (or similar) as \u201cenough\u201d?

", "time": "2025-07-21T13:46:57Z"}, {"author": "Mike Ounsworth", "text": "

@Chairs -- I think we need to stop and define \"What we're talking about\" concretely (ie Charter Text) _before_ we proceed to \"Should we work on it\".
\nI suspect we won't get convergence that we're all talking about the same thing.

", "time": "2025-07-21T13:47:01Z"}, {"author": "Eric Rescorla", "text": "

@Benjamin Schwartz ? Maybe I'm not sure if this will work on generic enclaves?

", "time": "2025-07-21T13:47:08Z"}, {"author": "Stuart Card", "text": "

I get more interested if we follow someone's question (Bob M's?) about maybe we should do this not only in TLS but also DTLS and/or IPSEC...

", "time": "2025-07-21T13:47:28Z"}, {"author": "Eric Rescorla", "text": "

But, like on AWS, you typically terminate at the AWS front end

", "time": "2025-07-21T13:47:32Z"}, {"author": "Jonathan Hoyland", "text": "

@Eric, if you allow AWS to terminate your TLS then the EAs won't validate.

", "time": "2025-07-21T13:48:14Z"}, {"author": "Jonathan Hoyland", "text": "

(Unless you are willing to share secrets with the AWS frontend)

", "time": "2025-07-21T13:48:40Z"}, {"author": "Eric Rescorla", "text": "

@Jonathan: well, unless AWS has some stuff for this.

", "time": "2025-07-21T13:48:40Z"}, {"author": "Watson Ladd", "text": "

@Uri : enough for what? The trusted third party case is really hard!

", "time": "2025-07-21T13:48:45Z"}, {"author": "Eric Rescorla", "text": "

I'm not quite sure why this is a complicated question. There was a whole list of companies that allegedly use TLS-based attestation. Are they going to switch to this?\"

", "time": "2025-07-21T13:50:05Z"}, {"author": "Jonathan Hoyland", "text": "

@Eric so if AWS is willing to compute and send the TLS Exporter to the enclave then you could totally make the protocol complete successfully, however you would have broken the security guarantees of the protocol.

", "time": "2025-07-21T13:50:24Z"}, {"author": "Dave Thaler", "text": "

\"there are a lot of companies not here\" is a reason IETF might not be the right place, if the companies who need to do it aren't at IETF

", "time": "2025-07-21T13:50:26Z"}, {"author": "Muhammad Sardar", "text": "

Confidential Computing Consortium, which has several companies in there, is waiting for it.

", "time": "2025-07-21T13:50:29Z"}, {"author": "Uri Blumenthal", "text": "

@Stuart, my point is that we should NOT do it \u201cin TLS\u201d or \u201cin IPsec\u201d. Because it\u2019s irrelevant for either.

\n

@Watson, \u201cenough\u201d as \u201cit does what we need, addressing both \u201cnecessary\u201d and \u201csufficient\u201d - no need to add anything to it.

", "time": "2025-07-21T13:50:54Z"}, {"author": "Dave Thaler", "text": "

A statement from CCC about the companies would indeed be useful

", "time": "2025-07-21T13:51:09Z"}, {"author": "Eric Rescorla", "text": "

Dave Thaler said:

\n
\n

A statement from CCC about the companies would indeed be useful

\n
\n

Precisely!

", "time": "2025-07-21T13:51:25Z"}, {"author": "Henk Birkholz", "text": "

There is large overlap between bof proponents and CCC participants

", "time": "2025-07-21T13:53:16Z"}, {"author": "Muhammad Sardar", "text": "

David, Google is indeed part of Confidential Computing Consortium! Perhaps you need to have a chat with your colleagues in Confidential Computing.

", "time": "2025-07-21T13:53:27Z"}, {"author": "Henk Birkholz", "text": "

but I'll add that to the minutes, if that is not there yet, rn

", "time": "2025-07-21T13:53:32Z"}, {"author": "Benjamin Schwartz", "text": "

FYI, WhatsApp (which normally uses the Noise Protocol) uses RA-TLS for enclave computing: https://ai.meta.com/static-resource/private-processing-technical-whitepaper

", "time": "2025-07-21T13:53:52Z"}, {"author": "Stephen Farrell", "text": "

is there a charter bit that says \"won't be horrible for privacy\"?

", "time": "2025-07-21T13:54:00Z"}, {"author": "Uri Blumenthal", "text": "

+1 Stephen

", "time": "2025-07-21T13:54:19Z"}, {"author": "Muhammad Sardar", "text": "

Benjamin Schwartz said:

\n
\n

FYI, WhatsApp (which normally uses the Noise Protocol) uses RA-TLS for enclave computing: https://ai.meta.com/static-resource/private-processing-technical-whitepaper

\n
\n

and it is bad because it provides you no freshness guarantees.

", "time": "2025-07-21T13:54:36Z"}, {"author": "Hannes Tschofenig", "text": "

It seems that a number of companies believe that adding remote attestation to their communication protocol provides some value

", "time": "2025-07-21T13:54:39Z"}, {"author": "Muhammad Sardar", "text": "

Stephen Farrell said:

\n
\n

is there a charter bit that says \"won't be horrible for privacy\"?

\n
\n

Evidence is sent encrypted over secure channel. What kind of privacy concerns you have?

", "time": "2025-07-21T13:55:19Z"}, {"author": "Stephen Farrell", "text": "

I have all the privacy concerns:-)

", "time": "2025-07-21T13:55:37Z"}, {"author": "Benjamin Schwartz", "text": "

Muhammad Sardar said:

\n
\n

and it is bad because it provides you no freshness guarantees.

\n
\n

I'd like to learn more about your concern.

", "time": "2025-07-21T13:55:53Z"}, {"author": "Watson Ladd", "text": "

The contents of the attestation indicate what software is running

", "time": "2025-07-21T13:56:04Z"}, {"author": "Eliot Lear", "text": "

Is the expectation here that the attestor and attestation validator service is one implementation and the verifier is another?

", "time": "2025-07-21T13:56:17Z"}, {"author": "Uri Blumenthal", "text": "

I don\u2019t want my every peer to receive my attestation records!!

", "time": "2025-07-21T13:56:21Z"}, {"author": "Stuart Card", "text": "

Ideally attestation is of _properties_ of the software that is running.

", "time": "2025-07-21T13:56:42Z"}, {"author": "Muhammad Sardar", "text": "
I'd like to learn more about your concern.\n`````\n\nSure, here https://ieeexplore.ieee.org/document/10752524\n
", "time": "2025-07-21T13:56:42Z"}, {"author": "Dave Thaler", "text": "

@Watson the contents of the attestation indicate what software _was_ running at the time of measurement.

", "time": "2025-07-21T13:56:48Z"}, {"author": "Watson Ladd", "text": "

that's the other question :P

", "time": "2025-07-21T13:57:17Z"}, {"author": "Henk Birkholz", "text": "

@Usma:

\n

there approaches that allow for encrypted Claims in EAT (e.g., SD-CWT) today, but that is really going deeper into the solution space (trying to listen to Monty and not do that).

", "time": "2025-07-21T13:57:22Z"}, {"author": "Henk Birkholz", "text": "

@Eliot

\n
\n

Is the expectation here that the attestor and attestation validator service is one implementation and the verifier is another?

\n
\n

I do not understand the difference between \"attestation validator\" and \"verifier\". Could you elaborate a tiny bit?

", "time": "2025-07-21T13:58:30Z"}, {"author": "Mike Ounsworth", "text": "

WG Milestone #1: produce a study document investigating various ways to accomplish the stated goals.
\nWG Milestone #2: pick one.

", "time": "2025-07-21T13:59:10Z"}, {"author": "Muhammad Sardar", "text": "

RA-TLS only ensures the state of the machine at some point in time in the past. It does not ensure the current state.

", "time": "2025-07-21T13:59:23Z"}, {"author": "Henk Birkholz", "text": "

@Usma: yes, you are right... and I am still puzzled by RA-TLS

", "time": "2025-07-21T13:59:50Z"}, {"author": "Eliot Lear", "text": "

Forgive me, Henk, I'm probably getting my terminology wrong, but the validator speaks to a service to receive valid values for attestation. Would we expect that service and the attestor to be the same entityt?

", "time": "2025-07-21T14:00:05Z"}, {"author": "Muhammad Sardar", "text": "

Mike Ounsworth said:

\n
\n

WG Milestone #1: produce a study document investigating various ways to accomplish the stated goals.
\nWG Milestone #2: pick one.

\n
\n

Milestone 1 has already been done. We have a paper submitted on this. The state space has been fully explored.

", "time": "2025-07-21T14:00:20Z"}, {"author": "Mike Ounsworth", "text": "

Muhammad Sardar said:

\n
\n

Mike Ounsworth said:

\n
\n

WG Milestone #1: produce a study document investigating various ways to accomplish the stated goals.
\nWG Milestone #2: pick one.

\n
\n

Milestone 1 has already been done. We have a paper submitted on this. The state space has been fully explored.

\n
\n

Submitted where? How can a WG produce a document when the WG does not exist yet?

", "time": "2025-07-21T14:00:57Z"}, {"author": "Kathleen Moriarty", "text": "

@Mike - could be a research paper to a peer reviewed journal as the question is written

", "time": "2025-07-21T14:01:32Z"}, {"author": "Henk Birkholz", "text": "

maybe a paper is not an I-D? (actually asking, I assumed \"scientific paper\")

", "time": "2025-07-21T14:01:39Z"}, {"author": "Stuart Card", "text": "

+1 Jonathan

", "time": "2025-07-21T14:01:43Z"}, {"author": "Henk Birkholz", "text": "

+1 Kathleen

", "time": "2025-07-21T14:01:55Z"}, {"author": "Eric Rescorla", "text": "

So my nitpick here is that we should say \"after handshake completion\" because \"post-handshake\" is a technical term in TLS

", "time": "2025-07-21T14:01:57Z"}, {"author": "Mike Ounsworth", "text": "

I would suggest that the the WG strike a Design Team with good representation from the WG. If the academic literature is robust, then the DT should be able to accomplish its goal easily :)

", "time": "2025-07-21T14:02:30Z"}, {"author": "Mike Ounsworth", "text": "

I'm thinking of the recent CFRG KEM Combiners DT as a model.

", "time": "2025-07-21T14:03:40Z"}, {"author": "Jonathan Hoyland", "text": "

@Mike I think Usama means https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10752524

", "time": "2025-07-21T14:03:49Z"}, {"author": "Thom Wiggers", "text": "

I'm not sure if preventing the ability to build \"bad\" functionality on top of this is possible \u2014 as I don't think this can ever not be super application-defined in how it's going to be used / relied on

", "time": "2025-07-21T14:03:54Z"}, {"author": "Stephen Farrell", "text": "

IMO the iETF ought consider abuse-cases as having equal weight to use-cases (we currently don't)

", "time": "2025-07-21T14:05:13Z"}, {"author": "Mike Ounsworth", "text": "

Jonathan Hoyland said:

\n
\n

@Mike I think Usama means https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10752524

\n
\n

Cool, then I restate:

\n

WG Milestone #1: Decide if https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10752524 sufficiently captures the charter of this WG.

\n

WG Milestone #2: pick a solution direction.

", "time": "2025-07-21T14:05:27Z"}, {"author": "Muhammad Sardar", "text": "

Jonathan Hoyland said:

\n
\n

@Mike I think Usama means https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10752524

\n
\n

no, the one I was mentioning was a survey paper currently under submission at Transactions on Dependable and Secure Computing

", "time": "2025-07-21T14:05:50Z"}, {"author": "Stuart Card", "text": "

In \"AAA\", I count 7 As: Attestation, Authentication, Authorization, Access control, Attribution, Accounting & Audit. They are all related but distinct and the overall scope of AAA is huge.

", "time": "2025-07-21T14:05:50Z"}, {"author": "Jonathan Hoyland", "text": "

@Mike +1

", "time": "2025-07-21T14:05:51Z"}, {"author": "Eric Rescorla", "text": "

I couldn't hear any of that from here

", "time": "2025-07-21T14:06:58Z"}, {"author": "Muhammad Sardar", "text": "

Mike Ounsworth said:

\n
\n

Jonathan Hoyland said:

\n
\n

@Mike I think Usama means https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10752524

\n
\n

Cool, then I restate:

\n

WG Milestone #1: Decide if https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10752524 sufficiently captures the charter of this WG.

\n

WG Milestone #2: pick a solution direction.

\n
\n

I was saying that we have already fully explored the space.

", "time": "2025-07-21T14:07:44Z"}, {"author": "Muhammad Sardar", "text": "

What do you find missing?

", "time": "2025-07-21T14:07:54Z"}, {"author": "Kathleen Moriarty", "text": "

@EKR - Daniel said that there are several companies that particiapte in ETSI & 3GPP that want a non-proprietary solution int his space

", "time": "2025-07-21T14:08:28Z"}, {"author": "Jonathan Hoyland", "text": "

@Muhammad can you point to a preprint of that survey? I think you may have explored the space, but people here haven't seen the result of that exploration

", "time": "2025-07-21T14:08:37Z"}, {"author": "Eric Rescorla", "text": "

Kathleen Moriarty said:

\n
\n

@EKR - Daniel said that there are several companies that particiapte in ETSI & 3GPP that want a non-proprietary solution int his space

\n
\n

I'd like to hear from them

", "time": "2025-07-21T14:08:54Z"}, {"author": "Kathleen Moriarty", "text": "

He wasn't willing to name names at the mic

", "time": "2025-07-21T14:09:09Z"}, {"author": "Eric Rescorla", "text": "

Kathleen Moriarty said:

\n
\n

He wasn't willing to name names at the mic

\n
\n

Well, that's a lot less persuasive, unfortunately

", "time": "2025-07-21T14:09:32Z"}, {"author": "Mike Ounsworth", "text": "

@Usama

\n
\n

I was saying that we have already fully explored the space.

\n
\n

That's great. Having robust literature to start with is excellent. But I'm assuming here that \"we\" is not the full WG. So any Milestone #1 MUST be about having the WG as a whole choose a specific version of the \"solution space overview\" to endorse.

", "time": "2025-07-21T14:09:36Z"}, {"author": "Kathleen Moriarty", "text": "

Just the messenger :-)

", "time": "2025-07-21T14:09:47Z"}, {"author": "Watson Ladd", "text": "

I don't think the WG needs to do a solution space overview to get something out

", "time": "2025-07-21T14:10:32Z"}, {"author": "Muhammad Sardar", "text": "

Mike Ounsworth said:

\n
\n

@Usama

\n
\n

I was saying that we have already fully explored the space.

\n
\n

That's great. Having robust literature to start with is excellent. But I'm assuming here that \"we\" is not the full WG. So any Milestone #1 MUST be about having the WG as a whole choose a specific version of the \"solution space overview\" to endorse.

\n
\n

Fair point.

", "time": "2025-07-21T14:10:42Z"}, {"author": "Hannes Tschofenig", "text": "

There are not many companies in the 3GPP producing the telco equipment - Ericsson, Huawei & Nokia

", "time": "2025-07-21T14:11:18Z"}, {"author": "Jonathan Hoyland", "text": "

There are also two sessions at least being discussed, the TLS session and the RATS attested session

", "time": "2025-07-21T14:12:03Z"}, {"author": "Stephen Farrell", "text": "

so none of any of this is supposed to work over QUIC I guess...

", "time": "2025-07-21T14:12:16Z"}, {"author": "Dave Thaler", "text": "

then rephrase the 4th bullet to be more clear :)

", "time": "2025-07-21T14:12:18Z"}, {"author": "Benjamin Schwartz", "text": "

I think RA-TLS is really the elephant in the room here. It's widely deployed and accepted by security auditors (perhaps despite some limitations!). IMHO success here would be about developing a standard that can broadly replace RA-TLS.

", "time": "2025-07-21T14:13:08Z"}, {"author": "Mike Ounsworth", "text": "

Maybe actually make the freshness point vaguer? \"Freshness to the satisfaction of the peer\" ?

", "time": "2025-07-21T14:13:27Z"}, {"author": "Hannes Tschofenig", "text": "

RA-TLS is not the elephant in the room. It is not widely deployed

", "time": "2025-07-21T14:13:30Z"}, {"author": "Dave Thaler", "text": "

Freshness _of what_ (since RFC 9334 talks about freshness of multiple things)

", "time": "2025-07-21T14:14:13Z"}, {"author": "Stephen Farrell", "text": "

https://ra-tls.com/ :-)

", "time": "2025-07-21T14:14:15Z"}, {"author": "Eric Rescorla", "text": "

I'm happy to workshop this if it gets to that

", "time": "2025-07-21T14:14:15Z"}, {"author": "Muhammad Sardar", "text": "

RA-TLS is the worst in the space, specifically for the VM-based TEEs.

", "time": "2025-07-21T14:14:22Z"}, {"author": "Stuart Card", "text": "

+1 Jonathan

", "time": "2025-07-21T14:14:37Z"}, {"author": "Muhammad Sardar", "text": "

RA-TLS may give you Evidence which is 2 years old.

", "time": "2025-07-21T14:14:44Z"}, {"author": "Mike Ounsworth", "text": "

Dave Thaler said:

\n
\n

Freshness _of what_ (since RFC 9334 talks about freshness of multiple things)

\n
\n

Well, right.
\nI'm aware that, for example, some very simple TPMs are effectively immutable hardware, so you can produce an Attestation (Evidence or AR)at manufacture time, and nothing in it will ever change. So what exactly does \"freshness\" mean here?

", "time": "2025-07-21T14:15:14Z"}, {"author": "Henk Birkholz", "text": "

@Dave: If it not Evidence or Attestation Result freshnes, I would be puzzled

", "time": "2025-07-21T14:15:29Z"}, {"author": "Jonathan Hoyland", "text": "

@Thom I think we're trying to do the first thing

", "time": "2025-07-21T14:15:31Z"}, {"author": "Dave Thaler", "text": "

I'd argue that Attestatoin Results are far more directly relevant here than Evidence (which is only indirectly relevant as far as it affects freshness of Attestatoin Results).

", "time": "2025-07-21T14:15:36Z"}, {"author": "Dave Thaler", "text": "

e.g. \"The protocol must allow a Relying Party to ensure that Attestation Evidence is fresh, even during the lifetime of a TLS session\". (not sure if that's what is meant but that's an example of the type of wording I want)

", "time": "2025-07-21T14:16:30Z"}, {"author": "Stephen Farrell", "text": "

i wonder if we're really at the \"delete bullet #3\" level of wordsmithing for this charter

", "time": "2025-07-21T14:16:31Z"}, {"author": "Henk Birkholz", "text": "

@Mike

\n
\n

Well, right.
\nI'm aware that, for example, some very simple TPMs are effectively immutable hardware, so you can produce an Attestation at manufacture time, and nothing in it will ever change. So what exactly does \"freshness\" mean here?

\n
\n

A RoT, such as a TPM, cannot create Evidence about itself

", "time": "2025-07-21T14:16:32Z"}, {"author": "Dave Thaler", "text": "

actually i meant \"\"The protocol must allow a Relying Party to ensure that Attestation Evidence is fresh, even during the lifetime of a TLS session\"\" as my example

", "time": "2025-07-21T14:16:56Z"}, {"author": "Dave Thaler", "text": "

darn cut and paste.. .let me try again

", "time": "2025-07-21T14:17:06Z"}, {"author": "Dave Thaler", "text": "

\"The protocol must allow a Relying Party to ensure that Attestation Results is fresh, even during the lifetime of a TLS session\"

", "time": "2025-07-21T14:17:13Z"}, {"author": "Henk Birkholz", "text": "

@Dave:

\n

I also would have assumed that Attestation Results are THE goto conceptual message here, but it seems in some scenarios Evidence seems to be the goal (despite the potential \"volume issue\" + \"which policy applies question\").

", "time": "2025-07-21T14:18:09Z"}, {"author": "Mike Ounsworth", "text": "

@Henk Birkholz

\n
\n

A RoT, such as a TPM, cannot create Evidence about itself

\n
\n

That's why I said \"Attestation\" and not \"Evidence\", because I don't think that level of specificity is helpful to the present discussion ;)

", "time": "2025-07-21T14:18:38Z"}, {"author": "Henk Birkholz", "text": "

@Dave:

\n
\n

The protocol must allow a Relying Party to ensure that Attestation Results is fresh, even during the lifetime of a TLS session

\n
\n

lgtm

", "time": "2025-07-21T14:18:44Z"}, {"author": "Benjamin Schwartz", "text": "

Hannes Tschofenig said:

\n
\n

RA-TLS is not the elephant in the room. It is not widely deployed

\n
\n

I'm not familiar with this protocol landscape, but last year Muhammad described it as \"the most common attested TLS protocol for confidential computing\".

\n

EDIT: I see you are coauthor on this statement as well?

\n

https://tu-dresden.de/ing/informatik/sya/professur-fuer-betriebssysteme/die-professur/termine/echtzeit-ag/a-rollercoaster-ride-on-the-formal-analysis-of-attested-tls

", "time": "2025-07-21T14:19:00Z"}, {"author": "Henk Birkholz", "text": "

@Mike: :troll::sweat_smile:

", "time": "2025-07-21T14:19:30Z"}, {"author": "Watson Ladd", "text": "

that and not widely deployed can both be true

", "time": "2025-07-21T14:19:46Z"}, {"author": "Kathleen Moriarty", "text": "

Paul's articulation is good IMO

", "time": "2025-07-21T14:21:31Z"}, {"author": "Muhammad Sardar", "text": "

Benjamin Schwartz said:

\n
\n

Hannes Tschofenig said:

\n
\n

RA-TLS is not the elephant in the room. It is not widely deployed

\n
\n

I'm not familiar with this protocol landscape, but last year Muhammad described it as \"the most common attested TLS protocol for confidential computing\".

\n

EDIT: I see you are coauthor on this statement as well?

\n

https://tu-dresden.de/ing/informatik/sya/professur-fuer-betriebssysteme/die-professur/termine/echtzeit-ag/a-rollercoaster-ride-on-the-formal-analysis-of-attested-tls

\n
\n

The most common does not necessarily imply the most secure. The two are different.

", "time": "2025-07-21T14:21:34Z"}, {"author": "Henk Birkholz", "text": "

@EKR: I am confused by your \"s/session/connection/\" request

", "time": "2025-07-21T14:21:49Z"}, {"author": "Eric Rescorla", "text": "

Henk Birkholz said:

\n
\n

@EKR: I am confused by your \"s/session/connection/\" request

\n
\n

\"session\" is not a defined term in TLS 1.3.

", "time": "2025-07-21T14:23:40Z"}, {"author": "Benjamin Schwartz", "text": "

@Muhammad Sardar I am totally supportive of developing and standardizing a suitable replacement for RA-TLS with stronger security properties. I would like to see some evidence of this goal in the charter, such as a liaison plan with CCC.

", "time": "2025-07-21T14:23:44Z"}, {"author": "Stuart Card", "text": "

+1 Deb

", "time": "2025-07-21T14:24:15Z"}, {"author": "Muhammad Sardar", "text": "

Also, things have changed. Industry is now moving to VM-based TEEs, which is what my claim was for. RA-TLS was originally defined for process-based TEEs like SGX.

", "time": "2025-07-21T14:24:23Z"}, {"author": "Stephen Farrell", "text": "

attested webRTC ;-)

", "time": "2025-07-21T14:24:38Z"}, {"author": "Dave Thaler", "text": "

+1 to listing CCC in the \"Dependencies and Liaisons\" section of the charter text

", "time": "2025-07-21T14:25:09Z"}, {"author": "Jonathan Hoyland", "text": "

Both using the same FQDN doesn't actually bind the layers at all.

", "time": "2025-07-21T14:25:50Z"}, {"author": "Yaroslav Rosomakho", "text": "

It should be usable for any protocol that provides \"exporter\" for channel binding. Is there a good reason not to extended to (in some future) SSH?

", "time": "2025-07-21T14:26:04Z"}, {"author": "Eric Rescorla", "text": "

Dave Thaler said:

\n
\n

+1 to listing CCC in the \"Dependencies and Liaisons\" section of the charter text

\n
\n

It would be nice to see a liaison from CCC that they want this!

", "time": "2025-07-21T14:26:13Z"}, {"author": "Muhammad Sardar", "text": "

Benjamin Schwartz said:

\n
\n

Muhammad Sardar I am totally supportive of developing and standardizing a suitable replacement for RA-TLS with stronger security properties. I would like to see some evidence of this goal in the charter, such as a liaison plan with CCC.

\n
\n

https://github.com/CCC-Attestation. Will add in liaison.

", "time": "2025-07-21T14:26:32Z"}, {"author": "Stephen Farrell", "text": "

@yaroslav: yes, it's hard enough to get the SSHM WG to do what's currently in charter:-)

", "time": "2025-07-21T14:26:44Z"}, {"author": "Jonathan Hoyland", "text": "

@Yaroslav I think RFC 5056 gives guidance on providing binding endpoints

", "time": "2025-07-21T14:27:54Z"}, {"author": "Jonathan Hoyland", "text": "

(Although I don't agree with all of it.)

", "time": "2025-07-21T14:28:17Z"}, {"author": "Yaroslav Rosomakho", "text": "

It would be... unfortunate to end up with a solution architecturally limited to TLS 1.3 and not portable to other secure transports.

", "time": "2025-07-21T14:28:27Z"}, {"author": "Ionu\u021b Mihalcea", "text": "

@Yaroslav - the plan was always to have this as a/the blueprint for other protocols :)

", "time": "2025-07-21T14:29:15Z"}, {"author": "Monty Wiseman", "text": "

While useful for CCC this SHOULD NOT be bound or have a dependency on a particular technology. This should be equally applicable to \"classical\" server workloads.

", "time": "2025-07-21T14:29:17Z"}]