[TLS] Re: Additional uses for SSLKEYLOGFILE entries

I fully agree. A common property of all the entries in the current format is Random from TLS ClientHello as the session key. I think it would be great to keep it that way. That is, I believe that new labels should only be used for potential future TLS extensions and protocols that are always enca

[TLS] Re: Reminder: Mail List Procedures

On Sat, Mar 1, 2025 at 9:57 AM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote: > On 01.03.25 06:27, Sean Turner wrote: > > • Discussion of subjects unrelated to IETF policy, meetings, activities, or > technical concerns (from RFC 3683) > > Could the chairs please clarify about

[TLS] Weekly github digest (TLS Working Group Drafts)

Pull requests - * tlswg/rfc8773bis (+1/-1/💬0) 1 pull requests submitted: - Making -04 (by seanturner) https://github.com/tlswg/rfc8773bis/pull/1 1 pull requests merged: - Making -04 https://github.com/tlswg/rfc8773bis/pull/1 * tlswg/tls-key-update (+1/-3/💬0) 1 pul

[TLS] The TLS-LTS Saga

TLS-LTS has now been rejected as an independent-track submission, the justification being -frozen. So the process for this draft was as follows: - I first posted it in 2016, and was asked to delay publication as an RFC until TLS 1.3 was finished, so as not to interfere with the 1.3 process. - Af

[TLS] Re: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hiya, I'm generally sympathetic to doing work in this space but I suspect we might need more and various advice for those who want to deploy ECH - just saying how to do trial decryption well likely won't be that useful IMO. Additional things where deployment advice may be needed may include: -