[Cryptography] NSA voting on TLS encryption at the IETF TLS WG

[Theodore Tso]

Andrew,

I haven't actively participated in IETF in quite some time (I was one
of the working group chairs for the ipsec wg when it was first
standardized), although I still follow the IETF mailing list (which is
where at least of the hijinks of Dan Bernstein have played out).  I
have my own opinion of Professor Bernstein given his interactions with
the IETF going back for many, many years, and suffice it to say that
at least for me personally, whatever respect his title of "professor"
might suggestion, his interactions have caused me to pretty much
disregsard him as a crank on matters relating to the IETF.  Each
person can decide forthemselves their own opinion of Professor
Bernstein.  I've just shared mine.

It's also clear to me that you don't understand how the IETF works,
and if you think putting something at the end is "burying", it's clear
you don't understand how the RFC documents are structured.  There are
all structured in a particular way, and "bury" implies a deliberate
attempt to hide information, which just weakens your arguments and
will make those who *do* understand less inclined to trust you.

> Silencing someone in the middle of a vote is questionable at best...

Again, it's not a vote.   You keep saying it, but it's Just Not So.

> I don’t see any indication that adding a stratified hierarchy to
> participants in an “open to all” forum is included in IETF policy.

As one of my mentors in the IETF once put it, there may be thousands
of people who drive trucks across a bridge, but you don't ask them how
to design a bridge properly (unless you want a lot of people to die).
So yes, there is absolutely a stratified hierarcy.  The last-call is
consensus of technical experts, and disagreements have to be backed by
valid technical arguments.  Having a buncho of people showing up
saying, "Ugh.  Don't Like" will cause the working group chair (who is
an expert empowered to judge whether there is a technical consensus of
by well-informed experts) to consider those arguments as not valid.

I am reminded of a time when someone who was clearly technically
clueless started objecting, and after a while, the working group chair
interrupted him, saying, "It's clear you don't know waht you are
talking about, so please understand that we will be ignoring you."
Afterwards, the working group chair was heard to have stated that he
was polite but firm.  To which another old-timer responded, "I see how
you were firm, but how were you polite?", and the working group chair
responded, "Because I waited so ***long***".  :-)

Ultimately, the IETF has no way of enforcing its standards, other than
its reputation for creating standards which are (a) high quality, and
(b) useful.  People will decide whether or not to implement an RFC
standard based on many factors.  There are those that are
informational RFC's that have very wide adoption, and those that are
standards track which don't get much adoption at all.

So if you think a pure ML-KEM Key Agreement is a bad idea, just don't
implement it.  It really is that simple.  The fact that it is proposed
as a informational RFC, and not on the standards track, is on the very
front page, makes it very clear that it is not something which is
being recommended, and you can hardly call the front page as "buried".

Whether any companies will implement this is probably more due to it
being something which might be required by some federal procurement
contracts and FIPS requirements, and not anything to do with the IETF.
Of course, what the federal government mandates doesn't necessarily
mean that the non-goverment world will accept it, with Exhibit one
being the Clipper Chip....

							- Ted