[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Hello everyone,
Apologies for any mistakes with utilizing the email list or bad headers; I
am getting familiar with the WG.
As it may be relevant for my following expressions, I have been a software
developer/engineer for several years and am a cybersecurity student.

I reiterate that I do not support the publication of this document.

Just because some people want to make it easier for others to use a less
powerful security mechanism doesn't mean that the IETF needs to assist
them. Anyone who really wants to use ML-KEM solo can do so.  Thank you to
everyone for the excellent concerns raised to protect users.

To those who are asking that we hurry to publish, I would ask for patience.
This document could affect millions of people for decades to come - it is
not something to be pushed out casually. The IETF uses (rough) consensus so
that all concerns may be heard and considered. I appreciated the table-like
ISO document someone linked that had a list of issues raised, the category
the issue was placed into, and a documented response, so that it was clear
that all grievances had been addressed. Adopting such a process here might
be useful in the future.

Sincerely,
  Sam Leavin


On Tue, Jul 7, 2026 at 7:47 PM <[email protected]> wrote:

> Send TLS mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TLS digest..."
>
> Today's Topics:
>
>    1. Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
>       (Jacob Appelbaum)
>    2. Re: Algorithm agility (Re: Re: WG Last Call: draft-ietf-tls-mlkem-08
> (Ends 2026-07-08))
>       (Nico Williams)
>    3. Re: New Version Notification for
> draft-sullivan-tls-xof-ciphers-00.txt
>       (Nick Sullivan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 7 Jul 2026 22:54:50 +0000
> From: Jacob Appelbaum <[email protected]>
> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends
>         2026-07-08)
> To: Joseph Salowey <[email protected]>, [email protected],
>         [email protected], [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Greetings tls-chairs and hello to other TLS-related folks,
>
> On 6/24/26 17:00, Joseph Salowey via Datatracker wrote:
> > This message initiates a new Working Group Last Call for draft-ietf-
> > tls-mlkem[1], which defines standalone ML-KEM key establishment for
> > TLS 1.3. The main question before the working group is: "Should the
> > working group publish a document specifying stand alone ML-KEM?".
>
> I do not support the publication of this document.
>
> > If
> > there is rough consensus then we will push to refine and publish the
> > document; otherwise, we will stop discussing the draft and not
> > progress it. Please respond to this call indicating whether you
> > support publishing a document specifying a stand alone ML-KEM.
> > Please refrain from further discussion on this topic as most
> > arguments have been discussed multiple times.
> >
> > Why are we holding this consensus call now?
>  >
>  > Significant developments have occurred both within this document and
>  > in the broader TLS ecosystem to address the concerns raised in the
>  > last WGLC. Therefore, the third consensus call is warranted. We ask
>  > the working group to consider document publication in light of these
>  > recent changes:
>  >
>
> Unfortunately, the reasons listed do not address several of my concerns.
>
> One of my primary concerns is the intentional removal by NIST of the
> hash call over the `m` value in FIPS 203 for ML-KEM before it is used
> internally by ML-KEM.Encaps(). Please consult Appendix C and
> specifically the third bullet point of C.1 on page 47 of FIPS 203 [0]
> for NIST's disclosure about this matter. The developments listed by Joe
> and Sean below do not mitigate the risk introduced by this change to
> Kyber as part of standardizing ML-KEM.
>
> To Nadim and Usama's credit: I found their formal modeling to be useful.
> When I last looked at the (symbolic) models, I understood that they did
> not model the RNG covert channel leakage concerns. This makes sense as
> it is internal to one part of ML-KEM, and the carrier of the covert
> channel is not directly visible on the wire as the covert channel itself
> is encrypted (e.g., the ciphertext is visible on the wire, but the
> covert channel encoded through `m` is not directly modeled as such).
> This is an unfortunate gap with symbolic models generally where
> cryptographic primitives are considered perfect as it makes some
> internal issues invisible. It is not a problem with their work; it is a
> problem with the primitive itself and the abstraction of symbolic models.
>
> Additionally the security considerations of the draft document in question:
>
> - do not mention outstanding technical concerns in the NIST process
> - do not link to the official comments in the NIST process
> - do not mention outstanding technical concerns in IETF discussions
> - do not give sufficient warning to those who are not cryptographers
> - do not give sufficient warning to cryptographic protocol engineers
> - do not mention the FIPS 203 requirement for NIST-approved randomness
> generation
>
> The last item is especially relevant - do endorsers of this non-hybrid
> ML-KEM draft all use ML-KEM only with NIST-approved randomness
> generation sources? Do they realize that this requirement is part of the
> security analysis? Again, hashing of `m` was removed intentionally and
> it is explained as part of the third bullet point of Appendix C in C.1
> on page 47 of FIPS 203 [0] for NIST's disclosure: "As this standard
> requires the use of NIST-approved randomness generation, this step is
> unnecessary and is not performed in ML-KEM." The security considerations
> of this document most certainly do not state that a NIST-approved
> randomness source is _required_. Nor do they explain that the removal of
> the hashing is considered secure only if that _required_ NIST-approved
> randomness source is used. The draft does not raise this clear and
> serious warning.
>
> The introduction by NIST of a covert channel in the design of Kyber as
> part of standardizing ML-KEM may lead to serious problems with TLS 1.3.
> No draft should promote ML-KEM without closing this covert channel.
> Instead, this draft implicitly relies on a NIST-approved randomness
> source as the mitigation for that covert channel. This is uncomfortably
> similar to how Dual_EC_DRBG, once NIST-approved, ended up being used in
> the real world despite being suitable for such covert channels.
>
> Ideally, I suggest closing the covert channel in the draft because doing
> so is trivial. This is separate from hedging with a hybrid construction.
> Relatedly, TLS 1.3 should also not reveal system randomness directly to
> the wire as several TLS implementations do today.
>
> Taken together, an adversary with a carefully placed kleptographic RNG
> backdoor will not even need an Extended Random draft this time around.
>
> I note that NIST did not engage with many of the official 2023 comments
> [1]. That limited engagement is concerning in light of NIST’s later
> disclosures about Dual_EC_DRBG, including its own email disclosure [2]
> between Don Johnson and John Kelsey. Dual_EC_DRBG also remains present
> in at least one widely deployed cryptographic library.
>
> For example, Bouncy Castle still contains a DualECSP800DRBG
> implementation [3][4] whose default P-256 Q point matches the
> (backdoored) value listed in the now-withdrawn NIST SP 800-90A Appendix
> A.1.1 [5, page 77].
>
> As the IETF takes no stance on the validity of patent claims, I propose
> a simple compromise to move the document along: in the next iteration of
> the draft, I would like to see the IETF require any ML-KEM
> implementation to hash `m` as Kyber did, and to state explicitly that
> relying on a NIST-approved randomness source is not an adequate
> mitigation for this concern. If reliance on NIST-approved randomness
> generation is retained, it should at least be explicitly required rather
> than implicitly endorsed by being buried deep within a comment in an
> appendix to FIPS 203. Such changes are interoperable even if other
> ML-KEM implementations do not make them. Hashing destroys the structure
> needed to exploit Dual_EC_DRBG and other similar kleptographic
> constructions.
>
> The draft could also encourage a similar strategy for all random bytes
> fields in TLS 1.3 that currently come directly from the system but that
> change is a better fit for a different draft. I would want to see
> changes made to ML-KEM and TLS 1.3 before I would feel confident that
> TLS 1.3 with ML-KEM was providing protection against serious large-scale
> adversaries.
>
> I have additional technical concerns as well as some additional
> technical mitigations. I am happy to share draft analysis and code with
> interested participants.
>
> Kind regards,
> Jacob Appelbaum
>
> [0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
> [1]
>
> https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf
> [2]
>
> https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-Development-Process/documents/Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
> [3]
>
> https://downloads.bouncycastle.org/java/docs/bcprov-jdk14-javadoc/org/bouncycastle/crypto/prng/drbg/SP80090DRBG.html
> [4]
>
> https://raw.githubusercontent.com/bcgit/bc-java/main/core/src/main/java/org/bouncycastle/crypto/prng/drbg/DualECSP800DRBG.java
> [5]
>
> https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-90a.pdf
>
>
> > - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a
> > separate consensus call, the WG agreed to promote the X25519MLKEM768
> > hybrid group to Recommended: Y in the IANA registry. Consequently,
> > the IANA registry will reflect a clear community preference for a
> > hybrid because Recommended: Y clearly indicates this while the
> > standalone ML-KEM groups defined in this draft remain Recommended:
> > N. The updated security considerations in [1] reference the IANA
> > registry to emphasize this preference.
> >
> > - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG
> > recently reached consensus to explicitly prohibit key share reuse
> > across connections in TLS 1.3. The new text changes the guidance
> > from SHOULD NOT to a strict MUST NOT. This resolves the concerns
> > regarding static key reuse and its associated privacy and forward-
> > secrecy risks for ML-KEM.
> >
> > - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and
> > hybrid KEM groups in TLS 1.3. This supports other results which show
> > that KEMs are secure when used in TLS 1.3 and that hybrid groups are
> > secure even if one of the components is compromised.
> >
> > - Liaisons: We received liaison statements from multiple SDOs
> > including  O-RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing
> > support for the publication of draft-ietf-tls-mlkem as an RFC as
> > they rely on the IETF to provide a stable normative reference.
> >
> > Please note that a third-party IPR disclosure exists [5] against
> > this document regarding patents related to the underlying ML-KEM
> > algorithm. This IPR declaration has not changed since the last WGLC.
> > As a reminder, per BCP 79, the IETF takes no stance on the validity
> > of patent claims, and the working group may decide to proceed with a
> > technology despite IPR disclosures if it decides that such use is
> > warranted.
> >
> > Conduct Reminder: Given the heated nature of previous discussions on
> > this topic, participants are strongly reminded to adhere to the IETF
> > Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep
> > feedback professional, technical, and focused on the document's
> > text.
> >
> > This working group last call will end on 2026-07-08.
> >
> > Joe and Sean
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ [2]
> > https://datatracker.ietf.org/liaison/2198/ [3] https://
> > datatracker.ietf.org/liaison/2151/ [4] https://datatracker.ietf.org/
> > liaison/2148/ [5] https://datatracker.ietf.org/ipr/search/?
> > submit=draft&id=draft-ietf-tls-mlkem
> >
> > _______________________________________________ TLS mailing list --
> > [email protected] To unsubscribe send an email to [email protected]
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 7 Jul 2026 18:12:32 -0500
> From: Nico Williams <[email protected]>
> Subject: [TLS] Re: Algorithm agility (Re: Re: WG Last Call:
>         draft-ietf-tls-mlkem-08 (Ends 2026-07-08))
> To: Soatok Dreamseeker <[email protected]>
> Cc: Jan Zerebecki <[email protected]>, [email protected]
> Message-ID: <ak2H4BW7BTuTgKg7@ubby>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jul 07, 2026 at 06:48:59PM -0400, Soatok Dreamseeker wrote:
> > > I don't know what you're arguing.  If your argument is "don't get this
> > > wrong", then I agree 100%.  If your argument harkens back to what I was
> > > originally responding to, namely that algorithm agility is bad, then I
> > > disagree 100%.
> >
> > If you wonder aloud why people are against algorithm agility and then are
> > astonished when someone explains how poorly thought-out algorithm agility
> > can introduce security footguns, I don't know what you expected. The
> > concept of algorithm agility is very broad.
>
> That's not really an answer to my question is it.  It comes off as a bit
> of an attempt at a personal gotcha.
>
> Past failures to get algorithm agility right do not and cannot mean that
> we must not do algorithm agility because it is unavoidable due to
> cryptographic algorithms aging out.  There is irreducible complexity
> involved.
>
> The debatable points are about how to do it, not whether to have it.  To
> that point I expressed a clear preference for doing it in-band, _inside
> TLS_ or whatever the protocol is rather than have to design new
> protocols with negotiation _somewhere_ and downgrade resistance.  If
> you're arguing for algorithm agility not-that-way, then say that.
>
> Nico
> --
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 7 Jul 2026 19:45:37 -0400
> From: Nick Sullivan <[email protected]>
> Subject: [TLS] Re: New Version Notification for
>         draft-sullivan-tls-xof-ciphers-00.txt
> To: [email protected]
> Message-ID:
>         <CAOjisRyPxrdm6=Dyo+7kUscZCM2mjZCkSx7-rqtT7f=
> [email protected]>
> Content-Type: multipart/alternative;
>         boundary="0000000000008fd5bc06560dfd63"
>
> Thanks, everyone. Let me take this person by person: restate each point so
> we're on the same page, then say where I land. (forgive the formatting,
> monospace was needed)
>
> *John Mattsson*
>
> You're suggesting the deck should do much more: fine-grained services from
> one deck function instead of assembling a protocol out of separate
> symmetric primitives, a lightweight roll for cheap per-message ratcheting,
> and the key schedule and record encryption folded into one running duplex
> rather than handed to a separate AEAD.
>
> We agree on the starting point: HMAC and HKDF are a poor base, and
> replacing them is the whole point of the draft. Where I stop short of you
> is going all the way to a duplex that does everything. It's an elegant end
> state, but not this draft: I want the new surface small enough to analyze,
> and record protection is throughput-bound, where a separate AEAD is the
> right tool for now. Ilari pushed back on the roll and the duplex directly,
> so I'll pick those up under him.
>
> *Markku Saarinen*
>
> You're pointing at the hardware chicken-and-egg: Keccak is fast in silicon
> but gets little of it, because software keeps reaching for AES and GCM, and
> you expect ML-KEM, ML-DSA, and full-round Keccak instructions to finally
> break the cycle, so we should build for where the hardware is heading.
>
> That's the premise the draft runs on: once Keccak is already in the stack
> for SHA-3, ML-KEM, or ML-DSA, the schedule reuses it for free. And when the
> full-round hardware you describe arrives, a duplex record layer, the kind
> of thing your BLINKER prototyped, is the natural next profile, which is
> exactly the endpoint John is after.
>
> *Ilari, on record protection*
>
> You already made the case against John's two record-layer ideas: a
> per-message roll runs into DTLS reordering and loss, and your own Keccak
> duplex record experiment wasn't fast enough to replace the AEAD.
>
> I agree, and that's why -00 leaves record protection to the AEAD and keeps
> KeyUpdate a full ratchet rather than a roll.
>
> *Martin Thomson*
>
> You'd keep the KDF choice off the cipher suite and negotiate it on its own,
> with 0 reserved for HKDF, and you flagged the cost: until the server
> selects, a client can be carrying several schedules at once, so keep the
> set small.
>
> Fair, and I'll take it. -00 bundles them today:
>
>   -00:  cipher suite = (AEAD, schedule)         one code point, bundled
>   -01:  cipher suite = AEAD
>         KDF extension = { 0 = HKDF, deck, ... }  negotiated separately
>
> That's a real change to how the draft frames itself, not a small edit, but
> I'd rather make it than defend the coupling. On the parallel cost, the case
> that bites is offering HKDF next to the deck, since that's SHA-2 against
> Keccak, two different hashes to carry until the server picks, the same cost
> TLS already pays for hash-agile suites. The two deck profiles aren't a
> second axis: they're one design at 12 and 24 rounds, SHAKE256 being the
> full-round one for FIPS conformance, so offering both is one codebase at
> two round counts. Keep the offered set small and that's the whole of it.
> I’d prefer TurboSHAKE if we’re selecting only one, but if FIPS is a target,
> people may prefer the “too much crypto” version for compliance reasons.
>
> *Ilari, on the schedule*
>
> You think -00 looks complicated, and you sketched a leaner one: a two-part
> [Left | Right] state, a Rachet that carries the Left half forward as the
> chain, and an Output off the Right half for every derived value. Here are
> the two side by side, aligned at the stage secrets the way the appendix
> aligns 8446 (no PSK, matching the count below):
>
>   deck (-00)                           Ilari
>
>   PSK                                  PSK
>    | absorb; Ratchet                    | Rachet
>    v                                    v
>   early_secret                         early_secret [L|R]
>    |                                    |
>    | absorb DHE, TH_SH                  | Rachet(Left, DHE)
>    v                                    v
>   H trunk (handshake)                  handshake_secret [L|R]
>    |  Fork: hs traffic                  |  Output(R): hs traffic
>    |                                    |
>    | Ratchet                            | Rachet(Left)
>    v                                    v
>   main_secret                          master_secret [L|R]
>    | absorb TH_SF                       |
>    v                                    |
>   T trunk (application)                 |  Output(R): app traffic,
>    |  Fork: app traffic,                |            exporter,
>    |        exporter, resumption        |            resumption
>
> It's essentially the same tree. The one structural difference: you keep an
> explicit handshake_secret, where the deck absorbs the key-exchange secret
> into a running trunk and forks from it, so the deck has two stage ratchets
> where you have three.
>
> On cost, counted on your scenario (no PSK, transcript set aside, since
> that's what your 15 covers):
>
>                             deck  Ilari
>   stage transitions            2      3
>   traffic secrets              4      4
>   record keys                  4      4
>   Finished (client+server)     4      2
>   exporter                     1      1
>   resumption                   1      1
>   total                       16     15
>
> So 16 to your 15. The single extra call is the separate MAC key: the deck
> spends two per Finished, expand finished_key then MAC, where you spend one
> Output, so plus two across the two Finisheds, minus one because the deck
> folds the handshake extract into an absorb instead of a third ratchet. One
> call apart, and that call is the tradeoff. Your Finished keys off
> Right(BaseKey), the traffic secret you also expand into its record keys, so
> a proof has to argue that one key is safe for both; the deck derives a
> separate finished_key, used for that MAC and nothing else (on SHAKE256,
> exactly KMAC256). One is a call cheaper, the other easier to reason about.
> Both are one XOF per derived value, which is where the saving over an HKDF
> schedule comes from, for both.
>
> On the proof, you're right that it needs one, and -00 is no different. A
> running trunk isn't the discrete extract-then-expand shape the existing TLS
> 1.3 results assume, so the chaining needs fresh analysis either way. The
> leaves are where the two diverge. The draft's leaves are built on analyzed
> constructions: the derivation is a keyed sponge with concrete keyed-duplex
> bounds, and the MAC is KMAC, whose framing gives the keyed separation and
> keeps a MAC from colliding with a derivation. Rachet and Output are one
> bare XOF at one domain, keyed by a prefix, so the keyed-PRF step and the
> MAC-versus-derivation separation are still open. The output carries
> HKDF-Expand-Label's labels. Rachet has none and leans on the chained state
> to keep the stages apart. Nothing there looks unsound, just less of it
> already written down and analyzed.
>
> *-01 action items*
>
> Pull the KDF into its own extension, 0 = HKDF; keep the separate-key MAC;
> leave record protection to a later profile; and take the running-state
> schedule to a real proof.
>
> Thanks, all! This is the read I was hoping for. Keep it coming.
>
> Nick
>
> On Tue, Jul 07, 2026 01:49 PM, "Markku-Juhani O. Saarinen" <
> [email protected]> wrote:
>
> > Yep,
> >
> >
> > For many years Keccak/SHA3 has had this chicken-and-egg problem wrt AES &
> > GCM, and SHA-2 too. While Keccak is faster in actual hardware, current
> > processors allocate a lot of real estate to the AES S-Boxes and carryless
> > multipliers, and hardly anything to Keccak. As a result, software
> engineers
> > keep using AES & GCM even more, not SHA3 at all -> processor makers
> invest
> > even more gates on AES & GCM and still hardly anything in SHA3.
> >
> >
> > With ML-KEM and ML-DSA making heavy use of Keccak, we may finally break
> > this cycle of doing 90s crypto forever -- and finally get full-round
> Keccak
> > vector instructions (that compute the entire f1600 in a few dozen cycles)
> > on more processors. This is "full keccak" approach substantially faster
> > than the partial SHA3 instructions available in, say, ARMv9. Such a
> Keccak
> > engine would, of course, make Duplex AEADs competitive or faster than
> AES &
> > GCM.
> >
> >
> > At the RISC-V PQC TG, the official full Keccak instruction has a
> > ratification plan targeting early next year. So, at present it is
> > restricted to experimental CPUs like the KaruCore processor we use as an
> HW
> > PoC (but it boots Linux and runs stock OpenSSL benchmarks!) Here's a
> > silly blog I wrote about running PQC benchmarks on it:
> > https://karucore.com/posts/pqc-and-keccak-on-karu/
> >
> >
> > *"TL;DR: The Keccak instruction vkeccak.vi <http://vkeccak.vi> proposed
> in
> > the PQC TG of RISC-V International is implemented in our karu64 core and
> > makes standard lattice-based PQC algorithms go 50% faster. The more you
> > optimize the rest, the bigger the Keccak share becomes and the greater
> the
> > relative benefit of having Keccak."*
> >
> >
> > I want "nice things" !  When building clean-slate things (brand-new CPUs
> > and brand-new TLS handshakes), we don't always have to consider the
> > limitations of technologies that we fully expect to go away anyway. And
> in
> > the meanwhile the older systems can happily coexist with the new.
> >
> >
> > Cheers,
> > -markku
> >
> > On Tue, Jul 7, 2026 at 7:54 PM Ilari Liusvaara <[email protected]
> >
> > wrote:
> >
> >> On Tue, Jul 07, 2026 at 06:08:10AM +0000, John Mattsson wrote:
> >> >
> >> > This seems like a great start!
> >> >
> >> > Instead of performing a full permutation for the relatively infrequent
> >> > key updates, it may be preferable to also use a lightweight "roll"
> >> > function to support inexpensive per-message ratcheting, similar to the
> >> > approach used by the Signal protocol.
> >>
> >> This seems to run into problems with reodering/loss in DTLS and AES
> being
> >> slow to rekey (Chacha is much faster here).
> >>
> >>
> >> > The current draft still hands off record protection to a separate
> AEAD,
> >> > with the deck function merely deriving the traffic keys. In my view,
> >> > this leaves one of the most compelling opportunities unexplored. The
> >> > key schedule and record encryption could be integrated into a single
> >> > running duplex object.
> >>
> >> Unfortunately, Keccak does not seem to be very good for this.
> >>
> >> I recently experimented with using Keccak for record protection. Testing
> >> core loop (the dominant cost for long messages) of an impractical AEAD
> >> (8-way interleaved TurboKeccak in duplex mode) gave ~6GBps on
> >> AMD 7900X(@65W).
> >
> >
> >>
> >> -Ilari
> >>
> >> _______________________________________________
> >> TLS mailing list -- [email protected]
> >> To unsubscribe send an email to [email protected]
> >>
> > _______________________________________________
> > TLS mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> >
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 16196 bytes
> Desc: not available
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
> ------------------------------
>
> End of TLS Digest, Vol 264, Issue 123
> *************************************
>

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]