Today, the IETF held the CURRENT BoF,
where the goal was to develop a new protocol.
That protocol would be substantially like TLS,
reusing its record layer and basic structure,
but it would drop in MLS for key exchange.
This is somewhere between a pretty bad idea
and a horrible idea.
The wholesale replacement of a huge chunk of protocol architectures
is a hallmark of a lot of the AI-generated protocol proposals
that have flooded the IETF.
A small blemish is identified,
then the fix is a whole new protocol,
or a major piece of surgery.
No regard for the wisdom of Chesterton’s Fence
or the accumulated knowledge and usefulness embodied in what exists.
Experienced engineers know that rewriting a code module
is not something you do lightly.
There’s lots of literature out there about why this is a bad idea generally,
and some emerging discussion about how AI might just change that.
The reasons not to rewrite a software component still largely apply
to a protocol component.
The reasons that AI might make it easier to do that safely, less so.
Protocols are different.
Wholesale Change Will Miss Use Cases
Just like with a code change,
a protocol component that changes will miss use cases
that people really care about.
The usual concerns with code apply:
- The existing features you know about and can test for
can be handled. - The existing problems you know and care about can be fixed.
- You inevitably introduce brand-new problems.
- The existing features you don’t know about
get lost.
Unlike code changes, you probably don’t have a test case
for existing features that you didn’t know about.
We found that with HTTP/2,
where a number of use cases got lost in the process
of “upgrading” HTTP.
In HTTP/1.1,
performing client authentication
in the middle of request was possible.
Losing that capability in HTTP/2
affected few enough people
that it was not badly damaging for the ecosystem.
It still sucked.
A lot of work was done to try to find these issues,
but we did not learn about these problems until fairly late in the process.
Proposing a protocol change means asking a whole lot of other people,
many of whom are not invested in your goals,
to do that work.
Changing a protocol by replacing a chunk of it,
no matter how much care is taken,
either asks the entire ecosystem to change with you.
That means asking everyone to move with you.
If they don’t, you are not changing the protocol,
you are forking it.
Forking A Protocol Destroys Interoperability
The real value of having a protocol like TLS
is that a great many things can all talk to each other.
Forking a protocol –
and sometimes profiling a protocol, a subject for another post –
destroys that.
You now have two ways to achieve the same goal,
and a choice to join one of two clubs.
You can join both, but that means constantly translating back and forth,
something that can only get harder over time
as protocol semantics diverge.
And yes, in case you were asking,
this applies to the entirety of the IETF IoT sphere,
which has parallel HTTP, TLS, and other analogues.
Ostensibly, these address the needs of highly constrained hardware,
but the cost is an ecosystem cut off from the mainstream.
But Fixing Protocols Is Hard
Yes, existing protocols come with baggage
or technical debt.
Maybe they aren’t perfectly optimized for your use.
The value that an existing protocol carries
is that you are sharing the burden of its maintenance
with a great many more people.
Fixing it, maybe by adding extensions to support your needs,
comes with opportunities to improve the protocol
even beyond that immediate need.
Every change is a chance to work off some of the accumulated cruft.
Major refreshes, like the TLS 1.3 reworking,
cleared out a ton of cruft in the process.
You get to benefit from the work that others do to improve that protocol too.
Do the Work
It is hard to be a responsible steward for the fabric of the Internet.
We do it because it is worthwhile.
Ignoring the lessons of the past is not helpful.
SOCIAL SHARE CARD GENERATOR