I believe we have addressed everything with a revised 1449. I closed #1451.
spt > On Jun 23, 2026, at 08:04, Sean Turner <[email protected]> wrote: > > Blame to go around. I looked at your PR: > https://github.com/tlswg/tls13-spec/pull/1449 > And thought well 9846 is obsoleting 8446 so implementers shouldn’t even look > at 8446 so the references in that list ought to be to 9846: > https://github.com/tlswg/tls13-spec/pull/1451 > I’ll try to synch up with ekr soonest to get this done. > > spt > >> On Jun 23, 2026, at 06:26, Deb Cooley <[email protected]> wrote: >> >> It is indeed 8446bis.... If you want to lean on him, do it. Sean may know >> better where that draft sits (who is holding the pen). >> >> I would think that a small change, like you propose would be fine (and I'm >> sort of surprised it wasn't flagged earlier). >> >> Deb >> >> On Tue, Jun 23, 2026 at 3:32 AM Hannes Tschofenig <[email protected] >> <mailto:[email protected]>> wrote: >>> I do not think it is me holding this up. I have given my approval a while >>> ago already. I believe the publication is blocked by the completion of >>> draft-ietf-tls-rfc8446bis. >>> >>> >>> >>> Am 23.06.2026 um 07:36 schrieb Martin Thomson: >>>> Hi everyone, >>>> >>>> This has taken far, far too long. What is the hold up? >>>> >>>> If the answer is Ekr, as I suspect it is, I might be able to help with >>>> that. Five months is totally unacceptable. >>>> >>>> Cheers, >>>> Martin >>>> >>>> p.s., I have a small patch to this that I would like to request. As the >>>> patient is open... >>>> (In short, one of the lines of hex has one character too many on one line. >>>> Moving that to the next line makes it neater.) >>>> >>>> ~~~ >>>> diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md >>>> index 922388c..836f4fe 100644 >>>> --- a/draft-ietf-tls-keylogfile.md >>>> +++ b/draft-ietf-tls-keylogfile.md >>>> @@ -467,22 +467,22 @@ CLIENT_RANDOM \ >>>> >>>> The following shows a log entry for a TLS 1.3 connection that successfully >>>> negotiated ECH. >>>> >>>> ~~~ application/sslkeylogfile >>>> ECH_SECRET \ >>>> 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ >>>> e8828ec09909cc9363179dc13b62498550c8637129345263011a1678370ca52a >>>> ECH_CONFIG \ >>>> 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ >>>> - fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d594\ >>>> - e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 >>>> + fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d59 \ >>>> + 4e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 >>>> CLIENT_HANDSHAKE_TRAFFIC_SECRET \ >>>> 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ >>>> a195b63ec4270609692a204c08e63e74d9ae58e377d11a383bfe641a63c01140 >>>> SERVER_HANDSHAKE_TRAFFIC_SECRET \ >>>> 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ >>>> 022d1cb827a90f27dadde0c99110c2b7d0f362fdfe420a04818aa223e5f2c14c >>>> CLIENT_TRAFFIC_SECRET_0 \ >>>> 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ >>>> c2310f7db71109de88bab6f2f433fdc1704aecc0d57349cbf9113e5033178172 >>>> SERVER_TRAFFIC_SECRET_0 \ >>>> ~~~ >>>> >>>> >>>> On Tue, Jan 6, 2026, at 11:28, Alanna Paloma wrote: >>>>> All, >>>>> >>>>> IANA has finished updating its registry accordingly and we now consider >>>>> AUTH48 complete: >>>>> https://www.rfc-editor.org/auth48/rfc9850 >>>>> >>>>> As this document is part of Cluster C430, you may track the progress of >>>>> all documents in this cluster through AUTH48 at: >>>>> https://www.rfc-editor.org/auth48/C430 >>>>> >>>>> We will move this document forward in the publication process once the >>>>> other necessary documents in the cluster complete AUTH48 as well. >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you, >>>>> Alanna Paloma >>>>> RFC Production Center >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
