Did he say they are all proved?
", "time": "2025-11-05T19:34:30.000Z"}, {"author": "Muhammad Usama Sardar", "text": "as in formally proved?
", "time": "2025-11-05T19:34:49.000Z"}, {"author": "Cory Benfield", "text": "I believe that was \"approved\"
", "time": "2025-11-05T19:35:08.000Z"}, {"author": "Sean Turner", "text": "The errata are either held for document update, approved, or rejected.
", "time": "2025-11-05T19:35:36.000Z"}, {"author": "Muhammad Usama Sardar", "text": "Thanks.
", "time": "2025-11-05T19:36:25.000Z"}, {"author": "Sean Turner", "text": "We had these: https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=table
\nand these:
\nhttps://www.rfc-editor.org/errata_search.php?rfc=9147&rec_status=15&presentation=table
NSS doesn't do any processing until the entire handshake message is available
", "time": "2025-11-05T19:39:24.000Z"}, {"author": "Carlos Melchor", "text": "o/
", "time": "2025-11-05T19:39:38.000Z"}, {"author": "Ira McDonald", "text": "EKR's mic is too hot and is distorting quite a lot
", "time": "2025-11-05T19:42:48.000Z"}, {"author": "Martin Thomson", "text": "he has it really close to his mouth, which is sometimes necessary, but not in this case
", "time": "2025-11-05T19:43:09.000Z"}, {"author": "Thom Wiggers", "text": "it kinda hurts to listen to remotely
", "time": "2025-11-05T19:43:35.000Z"}, {"author": "Yoav Nir", "text": "For IKEv2 you need to implement 5 or 6 extensions to get McEliece to work.
", "time": "2025-11-05T19:43:41.000Z"}, {"author": "Ira McDonald", "text": "EKR's mic overload will also spoil scrutability of the session recording. Asking him to back off the mic would be a good idea.
", "time": "2025-11-05T19:44:44.000Z"}, {"author": "Sean Turner", "text": "With these mics you kind of have to eat it
", "time": "2025-11-05T19:45:07.000Z"}, {"author": "Thom Wiggers", "text": "EKR is way too close, when he was a bit more chill like right now it's waaay better
", "time": "2025-11-05T19:45:46.000Z"}, {"author": "Martin Thomson", "text": "to be clear, this point about invalid content is one that QUIC solves. it's a little harder in TLS, where there is no authentication for the first flight. Would it make sense to add authentication to unencrypted packets?
", "time": "2025-11-05T19:46:19.000Z"}, {"author": "David Benjamin", "text": "Looks like the original report had some notes about ACKs at DTLS 1.2.
\nhttps://mailarchive.ietf.org/arch/msg/tls/ZEj04LyL3hJXeK1nsiOBoB2vCsg/
\n", "time": "2025-11-05T19:47:58.000Z"}, {"author": "David Benjamin", "text": "\n
\n- If a DTLS 1.2 (i.e. does not implement RFC 9147 at all) implementation
\n
\nreceives an ACK record for whatever reason, what happens? This decision we
\ndon't get to change. Rather, it is a design constraint. Both OpenSSL and
\nBoringSSL treat unexpected record types as a fatal error. I haven't checked
\nother implementations. So I think we must take as a constraint that you
\ncannot send an ACK unless you know the peer is 1.3-capable.
The problem is that an ACK is still a valid record, and it's mostly the record layer that has the loose behavior. Only the next layer goes \"ehh, what is this record type??\"
", "time": "2025-11-05T19:48:57.000Z"}, {"author": "Martin Thomson", "text": "Yeah, that seems suboptimal, but it only really builds the case against DTLS
", "time": "2025-11-05T19:51:42.000Z"}, {"author": "Martin Thomson", "text": "@Yaroslav Rosomakho if you want multiple keys, you can have multiple files. It is fairly straightforward to combine ECH configs.
", "time": "2025-11-05T19:52:43.000Z"}, {"author": "David Benjamin", "text": "I mean, I will not debate against any case against DTLS! :-) But in a hypothetical DTLS with authenticated unencrypted packets, this would still have broken, unless we decided ACKs used different encryption or something goofy.
", "time": "2025-11-05T19:53:20.000Z"}, {"author": "Martin Thomson", "text": "Or we had a different extension model that involved ignoring stuff you didn't understand
", "time": "2025-11-05T19:54:00.000Z"}, {"author": "Yaroslav Rosomakho", "text": "Sure. I think it would be more straightfoward to have EchConfig rather than EchConfigList in this context, but I guess that ship has sailed
", "time": "2025-11-05T19:54:12.000Z"}, {"author": "David Benjamin", "text": "Sure. If we said explicitly that unknown content types were ignored, then this would be straightforward.
", "time": "2025-11-05T19:54:21.000Z"}, {"author": "Martin Thomson", "text": "It's nice to have ECHConfigList, because that's the sequence of bytes you put in other places.
", "time": "2025-11-05T19:54:35.000Z"}, {"author": "Stephen Farrell", "text": "s/might/do/ want to end up with 1
", "time": "2025-11-05T19:56:14.000Z"}, {"author": "Bas Westerbaan", "text": "One please.
", "time": "2025-11-05T19:56:14.000Z"}, {"author": "David Benjamin", "text": "I do regret that the ECHConfigList includes those stupid two bytes in front as an artifact of the TLS presentation language. Makes everything needlessly annoying.
", "time": "2025-11-05T19:56:16.000Z"}, {"author": "Martin Thomson", "text": "I don't see the indirection via a public_name as something that provides useful features, only more risk.
", "time": "2025-11-05T19:57:06.000Z"}, {"author": "Stephen Farrell", "text": "critical X.509 extension == not happening
", "time": "2025-11-05T19:57:06.000Z"}, {"author": "David Benjamin", "text": "Martin Thomson said:
\n\n\nI don't see the indirection via a public_name as something that provides useful features, only more risk.
\n
I tend to agree. Just to consider why it'd be useful, we did discuss back when designing ECH \"what if you lost all your private keys, can you recover?\". The RPK mode does add an unrecoverable private key loss. But I dunno if I care very much either way.
", "time": "2025-11-05T19:59:58.000Z"}, {"author": "Stephen Farrell", "text": "the public_name might be used to route to the place with the ECH private key
", "time": "2025-11-05T20:02:51.000Z"}, {"author": "David Benjamin", "text": "Stephen Farrell said:
\n\n\nthe public_name might be used to route to the place with the ECH private key
\n
If you are doing that, then you actually need the outer SNI to be the public name.
", "time": "2025-11-05T20:03:15.000Z"}, {"author": "Dennis Jackson", "text": "Indeed. You could use the ConfigID at the cost of 1/256 GREASE clients also stopping by
", "time": "2025-11-05T20:03:39.000Z"}, {"author": "Bas Westerbaan", "text": "There is. There is \"mandatory\"
", "time": "2025-11-05T20:04:08.000Z"}, {"author": "Stephen Farrell", "text": "yep
", "time": "2025-11-05T20:04:13.000Z"}, {"author": "Martin Thomson", "text": "@David Adrian I thought that this would have been helpful in terms of making it possible to deploy
", "time": "2025-11-05T20:06:02.000Z"}, {"author": "Eric Rescorla", "text": "I just want to point out that I got my stuff done in <20 minutes, so it's on everyone else if this runs long
", "time": "2025-11-05T20:07:20.000Z"}, {"author": "Deirdre Connolly", "text": "@Eric Rescorla but you operate at 2X speed
", "time": "2025-11-05T20:07:42.000Z"}, {"author": "Martin Thomson", "text": "It's on the chairs, isn't it?
", "time": "2025-11-05T20:07:44.000Z"}, {"author": "Rich Salz", "text": "DTLSbis is not important to many people?
", "time": "2025-11-05T20:07:51.000Z"}, {"author": "Eric Rescorla", "text": "Rich Salz said:
\n\n\nDTLSbis is not important to many people?
\n
Good point
", "time": "2025-11-05T20:08:00.000Z"}, {"author": "Bas Westerbaan", "text": "Except that in the current draft, there is client state that can brick clients for a long while
", "time": "2025-11-05T20:09:32.000Z"}, {"author": "Stephen Farrell", "text": "these ideas don't change that
", "time": "2025-11-05T20:11:03.000Z"}, {"author": "Ted Hardie", "text": "Are the authors asking for adoption today?
", "time": "2025-11-05T20:11:36.000Z"}, {"author": "Christopher Patton", "text": "@Bas Westerbaan can you elaboarate at the mic? Totally understandable if it's too late in the evening
", "time": "2025-11-05T20:11:41.000Z"}, {"author": "Martin Thomson", "text": "this only allows two things:
\n@Dennis Jackson this was fixed with the HTTPS resource record (IP hints)
", "time": "2025-11-05T20:12:22.000Z"}, {"author": "Bas Westerbaan", "text": "Christopher Patton said:
\n\n\nBas Westerbaan can you elaboarate at the mic? Totally understandable if it's too late in the evening
\n
It's a bit late. Dennis can comment.
", "time": "2025-11-05T20:12:39.000Z"}, {"author": "David Benjamin", "text": "Rotation of RPK signing keys is... a little interesting.
", "time": "2025-11-05T20:12:46.000Z"}, {"author": "David Benjamin", "text": "Yeah, HTTPS-RR went through great pains to handle multi-CDN.
", "time": "2025-11-05T20:13:21.000Z"}, {"author": "Erik Nygren", "text": "I things implement the HTTPS RR TargetName handling properly then multi-CDN should work, but from discussions there are indications that implementers find this part of the spec hard to understand.
", "time": "2025-11-05T20:13:22.000Z"}, {"author": "Dennis Jackson", "text": "David: It's a list of PK hashes so rotation works the obvious way. Operatos could certainly get it wrong though.
", "time": "2025-11-05T20:14:03.000Z"}, {"author": "Stephen Farrell", "text": "IMO the PKIX one won't work out
", "time": "2025-11-05T20:14:21.000Z"}, {"author": "Dennis Jackson", "text": "Re Multi CDN: My comment was maybe more about how deployment has gone, rather than what the tech stack supports.
", "time": "2025-11-05T20:14:50.000Z"}, {"author": "Christopher Patton", "text": "RPK: If ECHConfigs are basically TOFU, would it be alright to ship the SPKI in the DNS record itself?
", "time": "2025-11-05T20:15:09.000Z"}, {"author": "Bas Westerbaan", "text": "So there is no one that wants to go for PKIX.
", "time": "2025-11-05T20:15:33.000Z"}, {"author": "Dennis Jackson", "text": "Chris: We ship the hash of the SPKI, smaller. Also lets us ship multiple
", "time": "2025-11-05T20:15:33.000Z"}, {"author": "Bas Westerbaan", "text": "Let's kill the PKIX method then.
", "time": "2025-11-05T20:15:35.000Z"}, {"author": "Martin Thomson", "text": "RPK is the only option I care about here
", "time": "2025-11-05T20:15:49.000Z"}, {"author": "Christopher Patton", "text": "How does the client get the public key, in either case?
", "time": "2025-11-05T20:15:52.000Z"}, {"author": "Erik Nygren", "text": "TOFU doesn't work for things like multi-CDN.
\n(you'd have to do try and then if it fails try again)
Also not in favor of cert-based.
", "time": "2025-11-05T20:16:04.000Z"}, {"author": "Dennis Jackson", "text": "In RPK: Get hash of SPKI. In Retry Config, get full PK and signature.
", "time": "2025-11-05T20:16:10.000Z"}, {"author": "Stephen Farrell", "text": "ah, I was hoping DJB would be the bonus:-)
", "time": "2025-11-05T20:16:14.000Z"}, {"author": "David Benjamin", "text": "The challenge is the client may be expecting stale RPK hashes (recovery is in large part about stale DNS), so the server needs to send a signature from basically every key they've ever had.
", "time": "2025-11-05T20:16:16.000Z"}, {"author": "Martin Thomson", "text": "The lack of indirection for RPK is not a big deal: you can always go back to DNS
", "time": "2025-11-05T20:16:19.000Z"}, {"author": "Christopher Patton", "text": "excellent, thanks Dennis
", "time": "2025-11-05T20:16:28.000Z"}, {"author": "David Benjamin", "text": "The public name + outer SNI model, for all its pains, has one nice property: even if you believe in a stale public name, as long as the client-facing server can still authoritatively speak for that public name, the outer SNI will correctly select that cert and get you the auth you're looking for.
", "time": "2025-11-05T20:16:58.000Z"}, {"author": "Dennis Jackson", "text": "DB: Yep. A signature from anything that a client could have for RPK. However, don't need to rotate RPK keys often. E.g. could be 90 days. Doesn't impact forward secrecy.
", "time": "2025-11-05T20:17:24.000Z"}, {"author": "Martin Thomson", "text": "There are two ways to do RPK: Either the config contains the public key; or the config contains a public key commitment (hash) and the update contains the public key.
", "time": "2025-11-05T20:17:32.000Z"}, {"author": "Dennis Jackson", "text": "DB: Yeah, that reason is partly why the PKIX method stuck around
", "time": "2025-11-05T20:17:38.000Z"}, {"author": "Christopher Patton", "text": "Yeah I'm liking RPK over PKIX for this.
", "time": "2025-11-05T20:17:50.000Z"}, {"author": "Mike Ounsworth", "text": "Tourist's view: isn't the point of ECH to obfuscate your CH from :eyes: as it goes over Web? If you end up talking to the wrong server, then you're gonna fail the pkix step of the real TLS handshake, right?
\nSo why are we talking about signing ECHConfig and ECH TOFU and other \"trust\" things?
@David Benjamin that problem is addressed by going back to DNS if you fail to authenticate a fallback config.
", "time": "2025-11-05T20:18:54.000Z"}, {"author": "Dennis Jackson", "text": "Mike: Hard to boil down to a short message, but this is about what happens when you have the 'wrong' ECH config because its stale or whatever. So there's no handshake with the right server, but you need a way to authenticate the retry config sent back to you by the server.
", "time": "2025-11-05T20:19:05.000Z"}, {"author": "Mike Ounsworth", "text": "Dennis Jackson said:
\n\n\nMike: Hard to boil down to a short message, but this is about what happens when you have the 'wrong' ECH config because its stale or whatever. So there's no handshake with the right server, but you need a way to authenticate the retry config sent back to you by the server.
\n
So sortof a discoverability / recovery thing, rather than a trust thing?
", "time": "2025-11-05T20:19:49.000Z"}, {"author": "Dennis Jackson", "text": "Mike: Yes. If you like, the bug we're fixing is that the recovery authentication mechanism ALSO impacts the public SNI.
", "time": "2025-11-05T20:20:16.000Z"}, {"author": "Erik Nygren", "text": "Mike: in the multi-CDN setup there are different servers both with valid (often different) PKIX certs, but also with different ECH configs. The HTTPS/SVCB RRs are designed to bind the IPs (pointed to by TargetName) together with the ECHConfig.
", "time": "2025-11-05T20:20:34.000Z"}, {"author": "David Benjamin", "text": "Martin Thomson said:
\n\n\nDavid Benjamin that problem is addressed by going back to DNS if you fail to authenticate a fallback config.
\n
That was my original proposal before we landed on this inner/outer handshake dance. I was unable to convince people it was safe enough, given how many layers of caching DNS has. Had to be sure we will actually get a fresh record. If we could be sure of that, we wouldn't need any of this! Go back to DNS and move on.
", "time": "2025-11-05T20:20:44.000Z"}, {"author": "Martin Thomson", "text": "This is QUIC Preferred Address for TLS. That it requires a new TCP flow is unfortunate.
", "time": "2025-11-05T20:20:52.000Z"}, {"author": "Muhammad Usama Sardar", "text": "In this figure, R1 just forwards the ClientHello?
", "time": "2025-11-05T20:21:19.000Z"}, {"author": "Martin Thomson", "text": "David Benjamin said:
\n\n\nMartin Thomson said:
\n\n\nDavid Benjamin that problem is addressed by going back to DNS if you fail to authenticate a fallback config.
\nThat was my original proposal before we landed on this inner/outer handshake dance. I was unable to convince people it was safe enough, given how many layers of caching DNS has. Had to be sure we will actually get a fresh record. If we could be sure of that, we wouldn't need any of this! Go back to DNS and move on.
\n
I think that you still need something like what we have for DNS caching reasons, but going back to DNS could be part of the overall risk management plan
", "time": "2025-11-05T20:21:57.000Z"}, {"author": "Erik Nygren", "text": "For HTTPS this is also Alt-Svc which never got critical mass implementation for alternate server names.
", "time": "2025-11-05T20:22:00.000Z"}, {"author": "Martin Thomson", "text": "@Erik Nygren or Alt-SVCB :)
", "time": "2025-11-05T20:22:18.000Z"}, {"author": "Erik Nygren", "text": "(but not exactly, but had a similar set of use-cases)
", "time": "2025-11-05T20:22:23.000Z"}, {"author": "Erik Nygren", "text": "right. :)
", "time": "2025-11-05T20:22:25.000Z"}, {"author": "David Benjamin", "text": "(Er, \"unable to convince people\" is probably too strong. I had no priors and was just trying to get ECH into a deployable state. I agreed with folks that going back to DNS was not good enough.)
", "time": "2025-11-05T20:23:07.000Z"}, {"author": "Mike Ounsworth", "text": "So, still in my tourist's view (ie: I understood like 60% of the well-intentioned words used to explain this to me.)
\nSounds like the failover / failback stuff matters. Sounds like building in a strong authentication model is overkill engineering?
(ECH has enough uphill battles to get deployed, without also scaring every SRE into thinking they will blackhole their domains. So we really wanted to mitigate that footgun.)
", "time": "2025-11-05T20:23:56.000Z"}, {"author": "David Benjamin", "text": "@Mike Ounsworth The challenge is in getting both:
\nThat means having some kind of as-good-as-your-source-DNS-record authentication on the rollback signal. It's a very messy thing.
", "time": "2025-11-05T20:26:46.000Z"}, {"author": "Mike Ounsworth", "text": "David Benjamin said:
\n\n\nMike Ounsworth The challenge is in getting both:
\n\n
\n- Make ECH fully rollback-safe, and robust to the caching mess that is DNS
\n- Attacker cannot make you think some ECH config was \"rolled back\" the wrong key or disabled by the server when it wasn't
\nThat means having some kind of as-good-as-your-source-DNS-record authentication on the rollback signal. It's a very messy thing.
\n
Yeah, right, ok, I get that.
\nBUT security modelling (in the real world) is Risk = Cost x Likelihood. IE don't spend more on security than the thing you're protecting. If replacing a passport costs $100; don't spend $1000 on a fire safe.
\nWhat, exactly, is ECH protecting that could be compromised by an incompletely authenticated rollback mechanisms here?