[{"author": "Sean Turner", "text": "

test

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

what is this mTLS protocol

", "time": "2025-07-23T14:03:23Z"}, {"author": "Deirdre Connolly", "text": "

pass

", "time": "2025-07-23T14:03:27Z"}, {"author": "Christopher Patton", "text": "

\"monochrome TLS\"

", "time": "2025-07-23T14:03:42Z"}, {"author": "Deirdre Connolly", "text": "

multi-user TLS

", "time": "2025-07-23T14:03:53Z"}, {"author": "Deirdre Connolly", "text": "

multicast TLS

", "time": "2025-07-23T14:03:59Z"}, {"author": "Alicja Kario", "text": "

\"mutual TLS\" = marketing name for for certificate based client auth

", "time": "2025-07-23T14:04:01Z"}, {"author": "Sean Turner", "text": "

https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/

", "time": "2025-07-23T14:04:01Z"}, {"author": "Dennis Jackson", "text": "

maybe TLS

", "time": "2025-07-23T14:04:03Z"}, {"author": "Mike Ounsworth", "text": "

Thom Wiggers said:

\n
\n

what is this mTLS protocol

\n
\n

Dunno. It probably adds RSA-1_5 encryption back.

", "time": "2025-07-23T14:04:09Z"}, {"author": "Sean Turner", "text": "

:smiley:

", "time": "2025-07-23T14:04:27Z"}, {"author": "Daniel Gillmor", "text": "

@meetecho, please move the speaker camera so it shows the speaker

", "time": "2025-07-23T14:04:38Z"}, {"author": "Daniel Gillmor", "text": "

thank you!

", "time": "2025-07-23T14:04:54Z"}, {"author": "Sean Turner", "text": "

@dkg thanks for noticing that!

", "time": "2025-07-23T14:05:10Z"}, {"author": "Uri Blumenthal", "text": "

Funny to hear that - in my experience with authentication via smart cards, Firefox, Chrone, Safari, MS Edge - all had no problem to prompt me for a smart card PIN.
\nWhat browser did you find that has UI problems here???

", "time": "2025-07-23T14:05:18Z"}, {"author": "Daniel Gillmor", "text": "

i just didn't want to look at you and joe any longer, Sean!

", "time": "2025-07-23T14:05:28Z"}, {"author": "Alicja Kario", "text": "

@Uri: that's the issue: asking for smartcard when the user doesn't have one

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

they don't like alpn I guess

", "time": "2025-07-23T14:05:47Z"}, {"author": "Christopher Patton", "text": "

YES. ECH == handshake encryption, not just SNI encryption

", "time": "2025-07-23T14:06:25Z"}, {"author": "David Benjamin", "text": "

@Uri Blumenthal I think their issue is that they don't want to prompt the browser. The trouble is whether the client knows that the CertificateRequest is meant for some other context than the user-facing smartcard, etc., auth that browsers do.

", "time": "2025-07-23T14:06:27Z"}, {"author": "Christopher Patton", "text": "

In other words, even if you're not a CDN, you should deploy ECH.

", "time": "2025-07-23T14:06:38Z"}, {"author": "Thom Wiggers", "text": "

@Uri: the problem is that CDN thinks you're a bot, pops the certificate request, and then suddenly you have that PIN popup on example.com

", "time": "2025-07-23T14:06:40Z"}, {"author": "Thom Wiggers", "text": "

that's just a jump scare

", "time": "2025-07-23T14:06:48Z"}, {"author": "Daniel Gillmor", "text": "

not to mention users who don't have a smartcard, etc.

", "time": "2025-07-23T14:07:04Z"}, {"author": "Uri Blumenthal", "text": "

@Alicja, if the user doesn\u2019t have certificates (on a smart card), she\u2019ll be unable to login - as simple as as that.

", "time": "2025-07-23T14:07:08Z"}, {"author": "Alicja Kario", "text": "

yes, and be scared by weird and unusual interactin

", "time": "2025-07-23T14:07:30Z"}, {"author": "Alicja Kario", "text": "

that's terrible UX

", "time": "2025-07-23T14:07:42Z"}, {"author": "Uri Blumenthal", "text": "

@David, prompting the user is the only way to ensure there\u2019s a human at the keyboard who really demands access.

", "time": "2025-07-23T14:08:07Z"}, {"author": "Daniel Gillmor", "text": "

\"don't bother the user, just leak their unique permanent identifier without asking them\"

", "time": "2025-07-23T14:08:20Z"}, {"author": "Watson Ladd", "text": "

do they? or are they just making popup go away

", "time": "2025-07-23T14:08:26Z"}, {"author": "David Benjamin", "text": "

Right, they're trying to get auth from another context, without triggering any \"unusual\" behavior in the other context. I.e. they want the other context to just present no certificate and continue anonymously.

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

Server: \"Hey browser, do you contain a .mil client cert? If so, echo DN.\"

", "time": "2025-07-23T14:08:52Z"}, {"author": "Watson Ladd", "text": "

there's also issues with being able to brand it, offer registration flows as an alternative, that drive people to use webauthn

", "time": "2025-07-23T14:08:57Z"}, {"author": "Uri Blumenthal", "text": "

I\u2019ve also used (successfully) soft certs - those without PIN. So, again, what seems to be the problem?

", "time": "2025-07-23T14:09:22Z"}, {"author": "Daniel Gillmor", "text": "

Uri, i've used them too. But i would bet that neither of us are normal web users.

", "time": "2025-07-23T14:10:01Z"}, {"author": "Thom Wiggers", "text": "

Uri: it's not about using certs as a user that expects it, it's about _not_ asking certs to users to users that don't expect it

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

So we proposed a version of req mTLS when the Server echoed the flag in the CertificateRequest, which allowed the client to disambiguate why the server asked for a cert.

", "time": "2025-07-23T14:10:58Z"}, {"author": "Eric Rescorla", "text": "

Well, you'd need like \"h3/mtls\"

", "time": "2025-07-23T14:10:58Z"}, {"author": "Dennis Jackson", "text": "

I think a lot of this could be solved by some tweaks to Jonathan Hoyland's client cert flag which is coming up for adoption.

", "time": "2025-07-23T14:11:06Z"}, {"author": "Uri Blumenthal", "text": "

If a server does require cert - then a user better have one. If a server can let the user in without authenticating her - fine, that\u2019s server policy. What\u2019s the problem?

", "time": "2025-07-23T14:11:29Z"}, {"author": "David Benjamin", "text": "

@Jonathan Hoyland I don't see how echoing the flag does anything for this problem.

", "time": "2025-07-23T14:11:34Z"}, {"author": "Uri Blumenthal", "text": "

Amazon doesn\u2019t ask me for a cert.

", "time": "2025-07-23T14:11:45Z"}, {"author": "Daniel Gillmor", "text": "

are we talking about mandating ECH for this?

", "time": "2025-07-23T14:12:02Z"}, {"author": "Alicja Kario", "text": "

Why Post Handshake Authentication is not good?

", "time": "2025-07-23T14:12:04Z"}, {"author": "Watson Ladd", "text": "

i'm not necessarily sure I understand this draft to be aimed at humans despite the presentation

", "time": "2025-07-23T14:12:11Z"}, {"author": "Christopher Patton", "text": "

Daniel Gillmor said:

\n
\n

are we talking about mandating ECH for this?

\n
\n

I don't think you'd need to.

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

It solves one of the problems. The client knows whether the server always asks for a cert, or is specifically responding to the flag.

", "time": "2025-07-23T14:12:20Z"}, {"author": "David Benjamin", "text": "

Roughly the two directions you can go here are:

\n", "time": "2025-07-23T14:12:26Z"}, {"author": "Brian Campbell", "text": "

the draft is not aimed at humans

", "time": "2025-07-23T14:12:32Z"}, {"author": "Daniel Gillmor", "text": "

if you don't mandate it, user identity will leak to the network.

", "time": "2025-07-23T14:12:34Z"}, {"author": "Mike Ounsworth", "text": "

Uri Blumenthal said:

\n
\n

If a server does require cert - then a user better have one. If a server can let the user in without authenticating her - fine, that\u2019s server policy. What\u2019s the problem?

\n
\n

But I think that's missing the point. Of course if a cert is required, it is required.
\nThis is about causing confusing UX to users who don't know what a cert is, and it's about leaking client cert info to servers that have no business to see it.

", "time": "2025-07-23T14:13:27Z"}, {"author": "Daniel Gillmor", "text": "

ekr and uri are just chillin' in the :locked:'ed queue?

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

So I think people are overrating what ECH can do here. It's a backup measure, not (regrettably) a primary security feature

", "time": "2025-07-23T14:14:53Z"}, {"author": "Uri Blumenthal", "text": "

Yes we are :smiley:

", "time": "2025-07-23T14:14:55Z"}, {"author": "Yoav Nir", "text": "

The flashing \"time is over\" worked well the the expired certificate subject.

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

And the reason that's OK is that if you can interfere with ECH, then you can you can see the domain name for SNI anyway.

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

Mike Ounsworth said:

\n
\n

Uri Blumenthal said:

\n
\n

If a server does require cert - then a user better have one. If a server can let the user in without authenticating her - fine, that\u2019s server policy. What\u2019s the problem?

\n
\n

But I think that's missing the point. Of course if a cert is required, it is required.
\nThis is about causing confusing UX to users who don't know what a cert is, and it's about leaking client cert info to servers that have no business to see it.

\n
\n

We're specifically talking about an endpoint that supports mixed authenticated and unauthenticated traffic.

", "time": "2025-07-23T14:15:37Z"}, {"author": "Christopher Patton", "text": "

Daniel Gillmor said:

\n
\n

if you don't mandate it, user identity will leak to the network.

\n
\n

Two thoughts here:

\n
    \n
  1. The property that ECH provides is full handshake encryption, which we wanted for TLS 1.3 and couldn't quite figure out at the time. This sort of use case is why full handshake encryption is so useful.
    2. \n
  2. There are workload types that don't necessarily care about privacy. For instance, GoogleBot is identified today by its source IP, which is already public. Humans should probably not use this extension w/o ECH.
    3. \n
", "time": "2025-07-23T14:15:58Z"}, {"author": "Eric Rescorla", "text": "

So, if you're worried about some non-SNI information leaking (e.g., the identity, as suggested by DKG) then ECH isn't good enough.

", "time": "2025-07-23T14:16:02Z"}, {"author": "Eric Rescorla", "text": "

@Chris: as above, I don't think ECH as-is is sufficient

", "time": "2025-07-23T14:16:24Z"}, {"author": "Uri Blumenthal", "text": "

@David, true, I don\u2019t understand, at least not fully. If a user doesn\u2019t know what a cert is - she has no business login in to a cert-protected web site.

", "time": "2025-07-23T14:16:27Z"}, {"author": "Daniel Gillmor", "text": "

ekr: can you outline more about why ECH is insufficient? because of fallback? or replay concerns? or something else?

", "time": "2025-07-23T14:16:46Z"}, {"author": "Jonathan Hoyland", "text": "

Uri Blumenthal said:

\n
\n

@David, true, I don\u2019t understand, at least not fully. If a user doesn\u2019t know what a cert is - she has no business login in to a cert-protected web site.

\n
\n

@Uri Blumenthal Think about identifying a crawler that visits a user facing website. You want to id the crawler but don't need to identify human users.

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

@DKG: because the key is delivered over an insecure channel

", "time": "2025-07-23T14:17:15Z"}, {"author": "Daniel Gillmor", "text": "

because you don't believe in DNSSEC?

", "time": "2025-07-23T14:17:36Z"}, {"author": "Dennis Jackson", "text": "

ECH is a very much a best effort measure at the moment. I think there'll be a draft at the end about making it more robust, but even that draft wouldn't solve this problem

", "time": "2025-07-23T14:17:53Z"}, {"author": "Christopher Patton", "text": "

well, ECH doesn't provide security at all unless you use DNS-over-HTTPS, for the same reason?

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

Yes. Browser clients don't do DNSSEC and they're not going to

", "time": "2025-07-23T14:17:58Z"}, {"author": "Jonathan Hoyland", "text": "

@Ekr, is the problem that DoH might not be used, or that DNSSEC isn't used?

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

The problem is DNSSEC won't be used.

", "time": "2025-07-23T14:18:14Z"}, {"author": "Christopher Patton", "text": "

i.e., the problem is not specific to this use case

", "time": "2025-07-23T14:18:18Z"}, {"author": "Eric Rescorla", "text": "

DOH is irrelevant

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

Uri Blumenthal said:

\n
\n

@David, true, I don\u2019t understand, at least not fully. If a user doesn\u2019t know what a cert is - she has no business login in to a cert-protected web site.

\n
\n

What about a website whose login page has a USERNAME : PASSWORD field, but will also prompt for a client cert, and skip the login page if provided?

", "time": "2025-07-23T14:18:31Z"}, {"author": "Daniel Gillmor", "text": "

DoH without DNSSEC doesn't solve the problem, because the resolver can then fake the ECH keys.

", "time": "2025-07-23T14:18:32Z"}, {"author": "Christopher Wood", "text": "

I assume the argument is that if ECH were to be used here then maybe they'd get ECH keys some other way, perhaps not via DNS

", "time": "2025-07-23T14:18:34Z"}, {"author": "Uri Blumenthal", "text": "

@Mike, I\u2019ve dealt with servers that require authentication to only part of the content they provide. Again, accessing both was very trivial - you login for the protected part access, and don\u2019t login for the rest of the web site.

\n

What\u2019s so difficult there???

", "time": "2025-07-23T14:18:40Z"}, {"author": "Martin Thomson", "text": "

I have some other options...

", "time": "2025-07-23T14:18:50Z"}, {"author": "Eric Rescorla", "text": "

@Patton: no, again, this is wrong. The reason that ECH is safe for SNI is that an attacker who can inject bogus ECH records already knows the domain name

", "time": "2025-07-23T14:19:06Z"}, {"author": "Christopher Patton", "text": "

Eric Rescorla said:

\n
\n

DOH is irrelevant

\n
\n

Mind expanding on this? Specifically, does the handshake parameter discussed here have less security than other handshake parameters?

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

For basically any other value besides SNI, ECH in fact doesn't safely protect them

", "time": "2025-07-23T14:19:33Z"}, {"author": "Felix Linker", "text": "

What is the difference between signalling that a certificate has been renewed and simply serving a valid certificate? I don't see the problem being discussed.

", "time": "2025-07-23T14:19:42Z"}, {"author": "Dennis Jackson", "text": "

Ekr is correct.

", "time": "2025-07-23T14:19:46Z"}, {"author": "Daniel Gillmor", "text": "

unless you require DNSSEC, ekr is right.

", "time": "2025-07-23T14:20:16Z"}, {"author": "Eric Rescorla", "text": "

I say this as someone who thinks ECH is important, but the reason we do the entire CH is for technical reasons, not that it really secures them.

", "time": "2025-07-23T14:20:19Z"}, {"author": "Christopher Patton", "text": "

I don't see why this is the case.

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

Uri Blumenthal said:

\n
\n

@Mike, I\u2019ve dealt with servers that require authentication to only part of the content they provide. Again, accessing both was very trivial - you login for the protected part access, and don\u2019t login for the rest of the web site.

\n

What\u2019s so difficult there???

\n
\n

Needing separate domains / ports for the server-auth-only vs mTLS content is annoying to manage. I want optional client cert on the whole thing.

", "time": "2025-07-23T14:20:41Z"}, {"author": "Watson Ladd", "text": "

@Uri: we don't have a way to do that in TLS 1.3+HTTP/2/3

", "time": "2025-07-23T14:20:47Z"}, {"author": "Thom Wiggers", "text": "

Even with authenticated DNS, ECH doesn't establish an end-to-end channel to the origin server

", "time": "2025-07-23T14:20:48Z"}, {"author": "Felix Linker", "text": "

Felix Linker said:

\n
\n

What is the difference between signalling that a certificate has been renewed and simply serving a valid certificate? I don't see the problem being discussed.

\n
\n

Aha. Long-lived sessions. Does TLS have some forward secrecy guarantees that should prevent any compromise to an existing session from a compromised private key? (I'd hope so)

", "time": "2025-07-23T14:20:59Z"}, {"author": "Watson Ladd", "text": "

it does

", "time": "2025-07-23T14:21:08Z"}, {"author": "Deirdre Connolly", "text": "

TLS 1.3 does

", "time": "2025-07-23T14:21:15Z"}, {"author": "Deirdre Connolly", "text": "

well

", "time": "2025-07-23T14:21:29Z"}, {"author": "Christopher Patton", "text": "

My understanding of at least Cloudflare's deployment of DNS-over-HTTPS is that you would always get the ECH config from a TLS server operated by the backend server. What's the attack?

", "time": "2025-07-23T14:21:35Z"}, {"author": "Deirdre Connolly", "text": "

Most implementations of TLS 1.3 do

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

@Patton: huh? I get my ECH config from my recursive resolver.

", "time": "2025-07-23T14:22:03Z"}, {"author": "Eric Rescorla", "text": "

That may or may not be CF

", "time": "2025-07-23T14:22:07Z"}, {"author": "Felix Linker", "text": "

+1 Bas

", "time": "2025-07-23T14:22:08Z"}, {"author": "Thom Wiggers", "text": "

++ Bas

", "time": "2025-07-23T14:22:13Z"}, {"author": "Felix Linker", "text": "

In case where a key is compromised without the server knowing it, I guess the new certificate can only mitigate that compromise if it uses a new key, and in that case, you will need to reconnect anyways to use that key, I presume.

", "time": "2025-07-23T14:23:05Z"}, {"author": "Christopher Patton", "text": "

Eric Rescorla said:

\n
\n

@Patton: huh? I get my ECH config from my recursive resolver.

\n
\n

OK, I may have my facts wrong here. I'll post on the list if I have follow-up, but for now feel free to assume I'm incorrect :)

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

Felix Linker said:

\n
\n

In case where a key is compromised without the server knowing it, I guess the new certificate can only prevent that attack if it uses a new key, and in that case, you will need to reconnect anyways to use that key, I presume.

\n
\n

Correct.

", "time": "2025-07-23T14:23:24Z"}, {"author": "Daniel Gillmor", "text": "

so many other things could be expired too, not just certificates. what about DNS TTLs (that were used to do domain validation in the first place)?

", "time": "2025-07-23T14:24:03Z"}, {"author": "Uri Blumenthal", "text": "

Very poor example - if I steal your private key once, why wouldn\u2019t I repeat the same thing the next month??? What miracle will protect you in 47 days?

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

the new vs. old cert comparison thing here could also be a PITA and easy to get wrong

", "time": "2025-07-23T14:24:35Z"}, {"author": "Uri Blumenthal", "text": "

+1 to Stephen

", "time": "2025-07-23T14:24:51Z"}, {"author": "Daniel Gillmor", "text": "

i feel like we're in Mickens' \"villains with fantastic (yet oddly constrained) powers\" territory (from https://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf )

", "time": "2025-07-23T14:25:34Z"}, {"author": "Sophie Schmieg", "text": "

I mean if any side of the connection at any point has reason to believe that they are communicating with the attacker, they should drop the connection immediately

", "time": "2025-07-23T14:25:34Z"}, {"author": "Sophie Schmieg", "text": "

don't talk to attackers

", "time": "2025-07-23T14:25:49Z"}, {"author": "Uri Blumenthal", "text": "

+1 to Daniel :wink:

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

I think it's important to distinguish between \"We have updated the keys\" and \"we have updated the certs\"

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

Sophie Schmieg said:

\n
\n

don't talk to attackers

\n
\n

Reminds me of a joke: \"Alice walks into a bar and gets a private key from Mallory, but thank goodness for MAL-BIND\".

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

Because it's the first one that creates the confusion

", "time": "2025-07-23T14:26:35Z"}, {"author": "Daniel Gillmor", "text": "

what about TLS session tickets? do we invalidate those after the certificate expiration?

", "time": "2025-07-23T14:27:06Z"}, {"author": "Eric Rescorla", "text": "

Rather, the complexity.

", "time": "2025-07-23T14:27:13Z"}, {"author": "Eric Rescorla", "text": "

Daniel Gillmor said:

\n
\n

what about TLS session tickets? do we invalidate those after the certificate expiration?

\n
\n

I don't think people do, nor should they

", "time": "2025-07-23T14:27:55Z"}, {"author": "Deirdre Connolly", "text": "

Mike Ounsworth said:

\n
\n

Sophie Schmieg said:

\n
\n

don't talk to attackers

\n
\n

Reminds me of a joke: \"Alice walks into a bar and gets a private key from Mallory, but thank goodness for MAL-BIND\".

\n
\n

Someone wrote down an intermediate attacker model where Mallory can manipulate the public key but not the secret key and that seemed more practical

", "time": "2025-07-23T14:28:01Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Mike Ounsworth said:

\n
\n

Sophie Schmieg said:

\n
\n

don't talk to attackers

\n
\n

Reminds me of a joke: \"Alice walks into a bar and gets a private key from Mallory, but thank goodness for MAL-BIND\".

\n
\n

Someone wrote down an intermediate attacker model where Mallory can manipulate the public key but not the secret key and that seemed more practical

\n
\n

yes one could check it, but

", "time": "2025-07-23T14:28:25Z"}, {"author": "Sophie Schmieg", "text": "

what is the use case for a TLS connection where I somehow care about the certificate expiring during the session? The certificate needs to be valid during the handshake, afterwards it doesn't matter anymore, does it?

", "time": "2025-07-23T14:28:34Z"}, {"author": "Uri Blumenthal", "text": "

Manipulate public key that\u2019s within a certificate, aka - signed by a CA?

", "time": "2025-07-23T14:28:58Z"}, {"author": "Mike Ounsworth", "text": "

@Deirdre Connolly , right I'm making a joke, but I think there is a legitimate CFRG discussion that we need to have about the practical value of MAL-BIND. A survey paper about where MAL-BIND does and doesn't apply to practical protocols would be SUPER helpful.

", "time": "2025-07-23T14:29:16Z"}, {"author": "Uri Blumenthal", "text": "

@Sophie, yes, that\u2019s the way I understand it.

", "time": "2025-07-23T14:29:28Z"}, {"author": "Eric Rescorla", "text": "

Sophie Schmieg said:

\n
\n

what is the use case for a TLS connection where I somehow care about the certificate expiring during the session? The certificate needs to be valid during the handshake, afterwards it doesn't matter anymore, does it?

\n
\n

... because even full compromise of the private key after connection formation isn't a problem

", "time": "2025-07-23T14:29:30Z"}, {"author": "Dmitry Belyavskiy", "text": "

@Sofie it looks like a grey zone to me

", "time": "2025-07-23T14:29:37Z"}, {"author": "Daniel Gillmor", "text": "

ekr: for TLS 1.3

", "time": "2025-07-23T14:29:54Z"}, {"author": "Eric Rescorla", "text": "

I wouldn't characterize the main

\n

Daniel Gillmor said:

\n
\n

ekr: for TLS 1.3

\n
\n

Correct, but that's the context of this proposal

", "time": "2025-07-23T14:30:03Z"}, {"author": "Robert Beck", "text": "

Sophie Schmieg said:

\n
\n

what is the use case for a TLS connection where I somehow care about the certificate expiring during the session? The certificate needs to be valid during the handshake, afterwards it doesn't matter anymore, does it?

\n
\n

This is the way it should be. Sometimes people try to do things where they try to tie session lifetime in a higher level protocol to the TLS certificate lifetime. IMO this is a bad idea.

", "time": "2025-07-23T14:30:14Z"}, {"author": "Deirdre Connolly", "text": "

Mike Ounsworth said:

\n
\n

Deirdre Connolly , right I'm making a joke, but I think there is a legitimate CFRG discussion that we need to have about the practical value of MAL-BIND. A survey paper about where MAL-BIND does and doesn't apply to practical protocols would be SUPER helpful.

\n
\n

latest drafts around hybrid KEMs basically say we care about LEAK and if we get MAL for free, great (because of the seed design we often get MAL for the hybrid KEM for free)

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

Brendan is an optimist about file cabinets

", "time": "2025-07-23T14:30:31Z"}, {"author": "Daniel Gillmor", "text": "

his filing cabinet has its own air conditioner

", "time": "2025-07-23T14:30:44Z"}, {"author": "Eric Rescorla", "text": "

This isn't the problem with CT monitoring, because there are services for that. The problem with CT monitoring is that you can't actually tell whether a new certificate is good or not. Like I routinely get notifications from Cloudflare about new certs for my domain and I'm pretty sure it's just Cloudflare and Netlify refreshing, but... maybe not?

", "time": "2025-07-23T14:31:24Z"}, {"author": "Mike Ounsworth", "text": "

Deirdre Connolly said:

\n
\n

Mike Ounsworth said:

\n
\n

Deirdre Connolly , right I'm making a joke, but I think there is a legitimate CFRG discussion that we need to have about the practical value of MAL-BIND. A survey paper about where MAL-BIND does and doesn't apply to practical protocols would be SUPER helpful.

\n
\n

latest drafts around hybrid KEMs basically say we care about LEAK and if we get MAL for free, great (because of the seed design we often get MAL for the hybrid KEM for free)

\n
\n

I can get behind that.

", "time": "2025-07-23T14:31:25Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Mike Ounsworth said:

\n
\n

Deirdre Connolly , right I'm making a joke, but I think there is a legitimate CFRG discussion that we need to have about the practical value of MAL-BIND. A survey paper about where MAL-BIND does and doesn't apply to practical protocols would be SUPER helpful.

\n
\n

latest drafts around hybrid KEMs basically say we care about LEAK and if we get MAL for free, great (because of the seed design we often get MAL for the hybrid KEM for free)

\n
\n

the settings where MAL really matters seem to be convoluted cryptocurrency/blockchain settings, but I do think a model between LEAK and MAL is salient (but not common in the literature so)

", "time": "2025-07-23T14:31:32Z"}, {"author": "Sophie Schmieg", "text": "

Robert Beck said:

\n
\n

Sophie Schmieg said:

\n
\n

what is the use case for a TLS connection where I somehow care about the certificate expiring during the session? The certificate needs to be valid during the handshake, afterwards it doesn't matter anymore, does it?

\n
\n

This is the way it should be. Sometimes people try to do things where they try to tie session lifetime in a higher level protocol to the TLS certificate lifetime. IMO this is a bad idea.

\n
\n

can they just not do that?

", "time": "2025-07-23T14:31:46Z"}, {"author": "Felix Linker", "text": "

Eric Rescorla said:

\n
\n

This isn't the problem with CT monitoring, because there are services for that. The problem with CT monitoring is that you can't actually tell whether a new certificate is good or not. Like I routinely get notifications from Cloudflare about new certs for my domain and I'm pretty sure it's just Cloudflare and Netlify refreshing, but... maybe not?

\n
\n

What do you mean by \"this\"? (The first word)

", "time": "2025-07-23T14:31:58Z"}, {"author": "Eric Rescorla", "text": "

Felix Linker said:

\n
\n

Eric Rescorla said:

\n
\n

This isn't the problem with CT monitoring, because there are services for that. The problem with CT monitoring is that you can't actually tell whether a new certificate is good or not. Like I routinely get notifications from Cloudflare about new certs for my domain and I'm pretty sure it's just Cloudflare and Netlify refreshing, but... maybe not?

\n
\n

What do you mean by \"this\"? (The first word)

\n
\n

Having to scrub the entire log

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

I'm also curious how the various BIND properties apply to privacy-preserving things. For example, in deniable encryption you actively don't want BIND-CT-PK. PAKEs probably also don't want certain BIND properties.

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

I'm a little puzzled why we're seeing this proposal in this WG. It's not TLS work

", "time": "2025-07-23T14:33:17Z"}, {"author": "Watson Ladd", "text": "

+1 ekr

", "time": "2025-07-23T14:33:40Z"}, {"author": "Robert Beck", "text": "

Sophie Schmieg said:

\n
\n

Robert Beck said:

\n
\n

Sophie Schmieg said:

\n
\n

what is the use case for a TLS connection where I somehow care about the certificate expiring during the session? The certificate needs to be valid during the handshake, afterwards it doesn't matter anymore, does it?

\n
\n

This is the way it should be. Sometimes people try to do things where they try to tie session lifetime in a higher level protocol to the TLS certificate lifetime. IMO this is a bad idea.

\n
\n

can they just not do that?

\n
\n

Of course they could just not do that. However participating in visits from the bad idea bears is such a glorious tradition with X.509 that it's often hard for them to resist doing so.

", "time": "2025-07-23T14:33:43Z"}, {"author": "Eric Rescorla", "text": "

To be clear, I'm totally open to a \"NewPKI WG\" that considers both this and Merkle Tree Certs

", "time": "2025-07-23T14:34:34Z"}, {"author": "Watson Ladd", "text": "

are the bad idea bears the same as the good idea fairy?

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

does smell a bit like something to consider in the upcoming mekletreecerts bof?

", "time": "2025-07-23T14:34:58Z"}, {"author": "Robert Beck", "text": "

Watson Ladd said:

\n
\n

are the bad idea bears the same as the good idea fairy?

\n
\n

similar, they're just more fun

", "time": "2025-07-23T14:34:58Z"}, {"author": "David Benjamin", "text": "

Eric Rescorla said:

\n
\n

To be clear, I'm totally open to a \"NewPKI WG\" that considers both this and Merkle Tree Certs

\n
\n

They're really very different things.

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

@Sophie Schmieg

\n
\n

Of course they could just not do that. However participating in visits from the bad idea bears is such a glorious tradition with X.509 that it's often hard for them to resist doing so.

\n
\n

Is ... am I ... the bear?

", "time": "2025-07-23T14:35:46Z"}, {"author": "Daniel Gillmor", "text": "

this is the IETF, we need to propose 6 ways to rewrite the existing webPKI and then endorse at least two of them.

", "time": "2025-07-23T14:36:14Z"}, {"author": "Dennis Jackson", "text": "

Daniel Gillmor said:

\n
\n

this is the IETF, we need to propose 6 ways to rewrite the existing webPKI and then endorse at least two of them.

\n
\n

And we have to do it every 5 to 7 years or so

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

and never actually move away it

", "time": "2025-07-23T14:36:53Z"}, {"author": "Sophie Schmieg", "text": "

and do the bears have bikes for the shed?

", "time": "2025-07-23T14:36:58Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

this is the IETF, we need to propose 6 ways to rewrite the existing webPKI and then endorse at least two of them.

\n
\n

Reaction_emoji: CAB/F_logo

", "time": "2025-07-23T14:37:04Z"}, {"author": "Jonathan Hoyland", "text": "

Does this require MUST-STAPLE?

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

Jonathan Hoyland said:

\n
\n

Does this require MUST-STAPLE?

\n
\n

I don't think so.

", "time": "2025-07-23T14:37:15Z"}, {"author": "Sophie Schmieg", "text": "

fairies obviously do not need bikes, due to having wings

", "time": "2025-07-23T14:37:17Z"}, {"author": "Mike Ounsworth", "text": "

Bears need a shed for all the bikes they stole from humans on the forest path?

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

Eric Rescorla said:

\n
\n

Jonathan Hoyland said:

\n
\n

Does this require MUST-STAPLE?

\n
\n

I don't think so.

\n
\n

If I want to serve a revoked cert, can't I just say \"I don't support this protocol\"?

", "time": "2025-07-23T14:38:13Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Deirdre Connolly said:

\n
\n

Mike Ounsworth said:

\n
\n

Deirdre Connolly , right I'm making a joke, but I think there is a legitimate CFRG discussion that we need to have about the practical value of MAL-BIND. A survey paper about where MAL-BIND does and doesn't apply to practical protocols would be SUPER helpful.

\n
\n

latest drafts around hybrid KEMs basically say we care about LEAK and if we get MAL for free, great (because of the seed design we often get MAL for the hybrid KEM for free)

\n
\n

the settings where MAL really matters seem to be convoluted cryptocurrency/blockchain settings, but I do think a model between LEAK and MAL is salient (but not common in the literature so)

\n
\n

Basically before the 'keeping up' paper, the Cryspen folks came up with this notion that's between LEAK and MAL, 'semi-honest collision resistance':
\nimage.png

\n
", "time": "2025-07-23T14:38:40Z"}, {"author": "Daniel Gillmor", "text": "

please also see the old CT gossip work that got more and more complicated in trans and never got to something implementable. \u2639

", "time": "2025-07-23T14:39:26Z"}, {"author": "Mike Ounsworth", "text": "

@Deirdre Connolly We might want to take this BIND thing over to #cfrg

", "time": "2025-07-23T14:39:27Z"}, {"author": "Watson Ladd", "text": "

running a log is ok provided you don't have it as the last tenant of a long forgotten hdfs cluster and a sysadmin dutifully checks for the other hdfs cluster no longer using the machine before decommisioning

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

@Jonathan Hoyland I see your point. Yes, I think it's something kind of like that, maybe HSTS-type things might work

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

Well, this discussion really makes me think we do need a NewPKI WG, that can incorporate cool ideas from multiple source.

", "time": "2025-07-23T14:41:11Z"}, {"author": "Robert Beck", "text": "

Watson Ladd said:

\n
\n

running a log is ok provided you don't have it as the last tenant of a long forgotten hdfs cluster and a sysadmin dutifully checks for the other hdfs cluster no longer using the machine before decommisioning

\n
\n

until the sysadmin is laid off and it runs hands off until 6 months later something stops and all of a sudden you can't order a burger so the world implodes.

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

NewPKI would be nice

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

Because I'm certainly not saying this doesn't have cool ideas.

", "time": "2025-07-23T14:41:30Z"}, {"author": "Eric Rescorla", "text": "

Just that we're not positioned to fix them

", "time": "2025-07-23T14:41:34Z"}, {"author": "Martin Thomson", "text": "

I think we came dangerously close to NewPKI at the DISPATCH session anyway

", "time": "2025-07-23T14:41:35Z"}, {"author": "Daniel Gillmor", "text": "

aren't we always dangerously close to NewPKI?

", "time": "2025-07-23T14:41:54Z"}, {"author": "Martin Thomson", "text": "

closer than ever before, perhaps

", "time": "2025-07-23T14:42:04Z"}, {"author": "Sean Turner", "text": "

don't we need a new encoding scheme first?

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

we haven't been close to a new PKI for 20+ years

", "time": "2025-07-23T14:42:10Z"}, {"author": "Daniel Gillmor", "text": "

not an actual new PKI in the world -- a \"newPKI\" WG.

", "time": "2025-07-23T14:42:35Z"}, {"author": "David Benjamin", "text": "

I'm obviously biased, but I think Merkle Tree Certificates is actually a fairly incremental change to the status quo, at least in comparison. But it's hard to fit details in 5 minutes.

", "time": "2025-07-23T14:42:43Z"}, {"author": "Eric Rescorla", "text": "

David Benjamin said:

\n
\n

I'm obviously biased, but I think Merkle Tree Certificates is actually a fairly incremental change to the status quo, at least in comparison. But it's hard to fit details in 5 minutes.

\n
\n

Maybe you could just compress the ideas using a Merkle Tree. /ducks

", "time": "2025-07-23T14:43:08Z"}, {"author": "Nicola Tuveri", "text": "

when is the BoF session where this will be discussed?

", "time": "2025-07-23T14:43:20Z"}, {"author": "Deirdre Connolly", "text": "

David Benjamin said:

\n
\n

I'm obviously biased, but I think Merkle Tree Certificates is actually a fairly incremental change to the status quo, at least in comparison. But it's hard to fit details in 5 minutes.

\n
\n

it's taking a status quo of multiple systems and parties and making a new thing

", "time": "2025-07-23T14:43:24Z"}, {"author": "Bas Westerbaan", "text": "

Nicola Tuveri said:

\n
\n

when is the BoF session where this will be discussed?

\n
\n

Watch saag. We'll mail lamps/tls.

", "time": "2025-07-23T14:43:34Z"}, {"author": "Bas Westerbaan", "text": "

(chairs allowing)

", "time": "2025-07-23T14:43:43Z"}, {"author": "Daniel Gillmor", "text": "

and shuffling the responsibilities of the parties a bit

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

the BoF would likely be next time or later

", "time": "2025-07-23T14:43:54Z"}, {"author": "David Benjamin", "text": "

Yup. Though the log structure is exactly the same, you can take one of the triply-implemented tiled log stacks, tweak the leaf structure and drop it in. The mirrors are doing basically the same thing as logs today, etc.

", "time": "2025-07-23T14:44:37Z"}, {"author": "Nicola Tuveri", "text": "

:thank_you:

", "time": "2025-07-23T14:44:41Z"}, {"author": "David Benjamin", "text": "

On the certificate side, it's modeled just as a funny sigalg. The general semantics of X.509 drop-in as-is (problematic as they are). The communication channels between the parties (client, server, CA, log/mirror) are all the same, etc.

", "time": "2025-07-23T14:45:28Z"}, {"author": "Mike Ounsworth", "text": "

@ekr -- for the minutes, what was your at-mic comment?

", "time": "2025-07-23T14:46:42Z"}, {"author": "Eric Rescorla", "text": "

@Mike Ounsworth So the issue here is that what you need to be attesting to (among other things) is \"The data you are about to encrypt will be handled in way X\". And that means that you can't allow new un-attested binaries to have access to the keys in the future.

", "time": "2025-07-23T14:47:41Z"}, {"author": "Eric Rescorla", "text": "

But that means that you have a much narrrower remit for re-attestation.

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

@ekr is \"your data will be handled in way X\" a superset of \"the device you are talking to is in state Y\"?

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

@Mike: well, you can always wrap it up in a new state. But in this case \"state Y\" needs to include \"The device cannot be put into state Z which violates any of the guarantees you are currently relying on\"

", "time": "2025-07-23T14:49:58Z"}, {"author": "Jonathan Hoyland", "text": "

Is the nonce different from the certificate_request_context?

", "time": "2025-07-23T14:50:00Z"}, {"author": "Daniel Gillmor", "text": "

ekr: this seems like one of the problems of RATS in the first place, no?

", "time": "2025-07-23T14:50:31Z"}, {"author": "Eric Rescorla", "text": "

So the relevant point is people were talking about the possibility that the peer would get updated to an arbitary new firmware load which (1) would have access to the current keys and (2) would need to be re-attested to.

", "time": "2025-07-23T14:50:45Z"}, {"author": "Daniel Gillmor", "text": "

you have to be able to reason about the transitions possible from the attested state.

", "time": "2025-07-23T14:50:48Z"}, {"author": "Eric Rescorla", "text": "

But the question is \"Why do you need to re-attest the new state\"?

", "time": "2025-07-23T14:51:04Z"}, {"author": "Watson Ladd", "text": "

well, the state isn't attested to. parts of it are, but a lot isn't

", "time": "2025-07-23T14:51:15Z"}, {"author": "Mike Ounsworth", "text": "

Eric Rescorla said:

\n
\n

@Mike: well, you can always wrap it up in a new state. But in this case \"state Y\" needs to include \"The device cannot be put into state Z which violates any of the guarantees you are currently relying on\"

\n
\n

The strawman I like to think of in these attestation cases includes attesting to things like \"I'm running Windows Patch X, and CorpAntiVirus with signatures updated on <date>\", which is of course mutable.

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

@Mike: right, but if Patch X+1 can exfiltrate the traffic keys, then this is an unsafe configuration

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

I guess I need to write an email about this

", "time": "2025-07-23T14:52:17Z"}, {"author": "Mike Ounsworth", "text": "

Yeah, \"What properties do I care about, but RATS fundamentally can't provide?\" is definitely too big for Zulip.
\nYou're needling at the extent to which you trust the device's vendor (or whoever holds the code-signing keys that the device trusts), which is a very big question.

", "time": "2025-07-23T14:53:46Z"}, {"author": "Jonathan Hoyland", "text": "

My question is what binds the EA used in Usama's protocol to RATS vs any other use of EAs? Do we need a context string in there?

", "time": "2025-07-23T14:54:01Z"}, {"author": "Watson Ladd", "text": "

well, then RATS proponents shouldnt put use cases dependent on those in their slides when justifing the work

", "time": "2025-07-23T14:54:23Z"}, {"author": "Christopher Patton", "text": "

@Muhammad Usama Sardar most drafts already have some description of the threat model and seucrity goals. This is what security considerations is for, no?

", "time": "2025-07-23T14:54:34Z"}, {"author": "Christopher Wood", "text": "

@JH sounds like they could use a channel binder

", "time": "2025-07-23T14:54:43Z"}, {"author": "Sean Turner", "text": "

@meetecho can we move the camera to the speaker?

", "time": "2025-07-23T14:54:52Z"}, {"author": "Thom Wiggers", "text": "

@CP ehhh I think that we can do better

", "time": "2025-07-23T14:55:08Z"}, {"author": "Christopher Patton", "text": "

Christopher Wood said:

\n
\n

@JH sounds like they could use a channel binder

\n
\n

uhm it's called a channel BINDING

", "time": "2025-07-23T14:55:09Z"}, {"author": "Christopher Wood", "text": "

My apologies

", "time": "2025-07-23T14:55:20Z"}, {"author": "Jonathan Hoyland", "text": "

@Chris Wood, you def. need a channel binding, the question is what needs to be bound :P

", "time": "2025-07-23T14:55:23Z"}, {"author": "Felix Linker", "text": "

I agree that such recommendations can live better in wikis or similar.

", "time": "2025-07-23T14:55:42Z"}, {"author": "Christopher Patton", "text": "

@Nick Sullivan I really hope we have time to hear about updates to implicit ECH

", "time": "2025-07-23T14:56:03Z"}, {"author": "Eric Rescorla", "text": "

Christopher Patton said:

\n
\n

Christopher Wood said:

\n
\n

@JH sounds like they could use a channel binder

\n
\n

uhm it's called a channel BINDING

\n
\n

Or like a channel holding hands

", "time": "2025-07-23T14:56:25Z"}, {"author": "Thom Wiggers", "text": "

nice slide theme

", "time": "2025-07-23T14:56:59Z"}, {"author": "Christopher Patton", "text": "

Thom Wiggers said:

\n
\n

@CP ehhh I think that we can do better

\n
\n

We could do better, but I don't think we need more formalisms for this. Like Deirdre is saying right now, let's treat FATT as an oracle that guides a particular draft toward the right end goal.

", "time": "2025-07-23T14:57:47Z"}, {"author": "Yoav Nir", "text": "

This encourages the (bad IMO) trend of working groups requiring an adopted draft to be very far along. We get drafts being discussed in the WG for years before adoption, followed by a WGLC a few months after adoption.

\n

We want them to be working groups, not rubber-stamping groups.

", "time": "2025-07-23T14:57:56Z"}, {"author": "Watson Ladd", "text": "

+1 Yoav

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

signed ECH: worth thinking about

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

Stephen Farrell said:

\n
\n

signed ECH: worth thinking about

\n
\n

Maybe with Merkle Trees

", "time": "2025-07-23T14:58:38Z"}, {"author": "Thom Wiggers", "text": "

I think that a wiki / some additional text in the FATT FAQ might be helpful to authors but yeah don't think this needs to be strict

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

I'd be a bit concerned about signed-ECH adding yet more complexity though

", "time": "2025-07-23T14:59:24Z"}, {"author": "David Benjamin", "text": "

Eric Rescorla said:

\n
\n

Stephen Farrell said:

\n
\n

signed ECH: worth thinking about

\n
\n

Maybe with Merkle Trees

\n
\n

ETC: ECH Transparent Certificates

", "time": "2025-07-23T14:59:45Z"}, {"author": "Eric Rescorla", "text": "

David Benjamin said:

\n
\n

Eric Rescorla said:

\n
\n

Stephen Farrell said:

\n
\n

signed ECH: worth thinking about

\n
\n

Maybe with Merkle Trees

\n
\n

ETC: ECH Transparent Certificates

\n
\n

10/10. No notes

", "time": "2025-07-23T15:00:07Z"}, {"author": "David Adrian", "text": "

ECK: Encrypted Certificates for Keys

\n

This way no one will know what the David's are talking about when we pronounce an acronym.

", "time": "2025-07-23T15:00:42Z"}, {"author": "Dennis Jackson", "text": "

Stephen: There's a straw-draft here: https://github.com/grittygrease/draft-sullivan-tls-implicit-ech/pull/9

", "time": "2025-07-23T15:00:48Z"}, {"author": "Daniel Gillmor", "text": "

ECH Key Refresh: ekr

", "time": "2025-07-23T15:01:35Z"}, {"author": "Eric Rescorla", "text": "

Well I think replace is interesting, definitely

", "time": "2025-07-23T15:02:21Z"}, {"author": "Dennis Jackson", "text": "

It's replace

", "time": "2025-07-23T15:02:30Z"}, {"author": "Martin Thomson", "text": "

replace is better

", "time": "2025-07-23T15:02:39Z"}, {"author": "Eric Rescorla", "text": "

Is part of this also requiring future ECH configs delivered via DNS to be signed

", "time": "2025-07-23T15:02:59Z"}, {"author": "Martin Thomson", "text": "

keep in mind that we have TOFU for this today anyway - the public name first appears in DNS and has no tie to a reference identity

", "time": "2025-07-23T15:03:04Z"}, {"author": "Eric Rescorla", "text": "

So it's like TOFU generlaly?

", "time": "2025-07-23T15:03:05Z"}, {"author": "Dennis Jackson", "text": "

No

", "time": "2025-07-23T15:03:06Z"}, {"author": "Eric Rescorla", "text": "

Is that something you considered and rejected?

", "time": "2025-07-23T15:03:32Z"}, {"author": "Dennis Jackson", "text": "

Ekr: nothing changes about the DNS ECHConfig, it just gains a list of hashes of a public key.

", "time": "2025-07-23T15:03:33Z"}, {"author": "Christopher Patton", "text": "

If there are multiple reasons to sign ECH -- it sounds like there are -- then we'd want to be able to support _any_ of those reasons but not necessarily _all_ of them, if that makes sense?

", "time": "2025-07-23T15:03:41Z"}, {"author": "Eric Rescorla", "text": "

Because we had this extensive discussions earlier about how the insecure delivery of ECH wasn't great.

", "time": "2025-07-23T15:03:56Z"}, {"author": "Stephen Farrell", "text": "

if I understand correctly (and probably don't) the TOFU approach here might be least hassley

", "time": "2025-07-23T15:04:05Z"}, {"author": "Daniel Gillmor", "text": "

+1 ben

", "time": "2025-07-23T15:04:37Z"}, {"author": "Dennis Jackson", "text": "

Ben: You want short lived HPKE keys for privacy / forward secrecy. You want long lived signing keys.

", "time": "2025-07-23T15:04:42Z"}, {"author": "Stephen Farrell", "text": "

I'd argue for this to be a differernt ECHConfig version too of course (and probably lose the argument again:-)

", "time": "2025-07-23T15:06:29Z"}, {"author": "Dennis Jackson", "text": "

Stephen: This can be a backwards compatible extension :-)

", "time": "2025-07-23T15:06:49Z"}, {"author": "Deirdre Connolly", "text": "

:wave:

", "time": "2025-07-23T15:07:06Z"}, {"author": "Benjamin Schwartz", "text": "

Eric Rescorla said:

\n
\n

So the relevant point is people were talking about the possibility that the peer would get updated to an arbitary new firmware load which (1) would have access to the current keys and (2) would need to be re-attested to.

\n
\n

I think this is basically a misunderstanding. The presenters were discussing an update to new firmware that is constrained by the previous firmware and TCB, which is constrained during the attestation.

", "time": "2025-07-23T15:07:08Z"}, {"author": "Eric Rescorla", "text": "

Well, then I don't understand why I need re-attestation ata ll

", "time": "2025-07-23T15:07:20Z"}]