[TLS] Re: Response to CoI Complaints

On Thu, Jul 16, 2026 at 09:22:38AM -0700, Andrew Lee wrote:
> Furthermore, the issue isn't whether or not Deb Cooley is a person of
> proper moral turpitude. Instead, it's whether a 37-year NSA veteran
> can serve as a neutral arbiter in a process where NSA employees are
> flooding the list in support, most of whom are participating for their
> first time, where NSA's CNSA 2.0 framework requires the exact outcome
> the NSA desires from this process, and where NSA's Canadian partner
> stated on-list [2] that they are waiting for this RFC so they can
> recommend solo ML-KEM nationally.

I guess you wouldn't object to former NSA employee Ed Snowden being an
AD in charge of TLS WG, so it's not really about NSA but about whether
Deb is plausibly an agent working under cover to sabotage Internet
specifications.

The objective answer is that the horse left the barn two decades ago
when the IETF decided to get out of fighting about national
cryptographic standards, therefore Deb's 37 years at the NSA are
irrelevant in this case, and you're fighting the wrong battle if you
want to change that two-decade-old decision.


What you're really litigating is a social death penalty for the NSA --
something we _could_ do, but shouldn't.  We really, really shouldn't do
that for at least several reasons, such as:

 - If the NSA wants to get burned again by playing the Dual_EC game
   again, let them!

 - The NSA is not likely the monolith a social death penalty for it
   would have to presume.

 - There is no technical content regarding ML-KEM to back this up.

   There is only the 1DES key weakening and the Dual_EC adventure, but
   these are not relevant to ML-KEM except in a FUD-y way.  And again,
   if your fears turn out to be true, then you win a big prize: more egg
   on the NSA's face.

   Yes, I know about `m` not being hashed.  No, I don't think that's
   particularly problematic for non-FIPS implementations because those
   can use any RNGs and whiten them as needed, and no peer could tell
   that they are not using a NIST DRBG.  Thus I don't think there is
   anything we can do regarding `m` other than give advice for non-FIPS
   implementations -- perhaps we should do that much, but that seems
   like something TLS and IETF should say much more generally in a BCP
   rather than in each Internet protocol RFC that somehow needs RNGs.

 - You and others are destroying your credibility and good will towards
   yourselves and towards the IETF by really reaching in your arguments
   against ML-KEM.

 - Why use up your/our political capital over ML-KEN -a relatively minor
   matter- rather than keeping the powder dry for a more important fight
   that might be around the corner?

 - We know they will go to IEEE if we don't publish.  IETF is much more
   open, so if we abdicate our remit to more closed SDOs, what will you
   have achieved with this social death penalty?  Nothing good, IMO.

Really, pick your fights carefully!

Nico
-- 

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