[TLS] "Do your own extension" considered harmful

[Nico Williams <[e-mail]>]

The ticketrequests I-D is likely to be the second time Viktor (and
others including me) have been told "do your own extension, we won't
oppose it, make it an individual submission, whatever, have fun and
leave us alone!".

There are several ways in which this attitude by the WG, by the relevant
I-D authors, and by the chairs, are harmful.

Let's focus on just one harm: feature matrix fragmentation.

One could stop right there.  No doubt we all understand exactly what
"feature matrix fragmentation" means.  Just in case though, let's flesh
it out.

Suppose we get enough of these "bleep off and do your own"[*] cases, and
so after a few years we have some number N of specialty extensions,
where N > M, where M is the number of extensions we would have had if
the WG's attitude had been more constructive.

What would that mean for application developers, and for TLS stack
developers / maintainers?

Well, an app developer might say "hey, I need these three extensions",
look, and find that no TLS stacks implement all three.  Sadness ensues.
Now the app developer might need to implement support for one or more
extensions in some open source TLS stack and wait a few months/years for
that to be integrated and ship.  Or worse! the app developer might have
to wait for a vendor to implement and ship.

And TLS stack devs/maints will have a nasty time of it too.  Besides
having a hard time approaching 100% feature matrix support, they might
find that some extensions don't fit their stacks' APIs very well and
require significant rototilling or worse, not even attempting to support
those extensions.  The latter is what happens when substantive feedback
is ignored by the WG.  And yet that is a major reason we should want WG
and IETF review: so that such impedance mismatches can be avoided where
possible.

Undoubtedly there is a cost to accepting substantive feedback.  E.g.,
delay and extra labor costs.  But that cost is limited by the process
that we have (only timely and substantive feedback needs to be
considered).  This cost mostly affects us, WG participants, and
implementors, while the feature matrix fragmentation problem's costs
affect primarily users and implementors.  On balance, I believe feature
matrix fragmentation is easily the costlier problem.


Maybe we want to consciously and explicitly accept this feature matrix
fragmentation issue, in which case here is a humble proposal: that all
TLS IANA registries be made Expert Review only, and that the TLS WG stop
accepting work items that don't involve substantial changes to the
protocol.


If the only objections or improvements we'll allow are security or
privacy concerns, but implementors' and users' concerns are to be
excluded, then we're impliedly headed towards feature matrix
fragmentation.  Besides, allowing authors to dictate what is and is not
in-scope for their documents is practically the same as rubber-
stamping, which is... not what we are supposed to be doing.


In any case, it's NOT OK for authors to refuse to consider substantive
feedback.  WGs should police reticent WG work item editors and authors.

I know, because I've been an editor/author who disliked where the WG was
headed with an I-D of mine and I had to accept it.  Indeed, I was
threatened by a WG chair with removal as editor.  I don't see why other
authors should not be subject to the same treatment.  That's not spite
but right.


Oh, and a word about the social harms caused by your attitude: there
goes good will.

Appeals, end-less and bitter [e-mail] threads, more rather than
less WG work item review specifically to find wrenches to throw into the
gears at the worst possible times -- these are things that the aggrieved
might resort to.  That's not a threat: I'm not a maintainer or developer
of a TLS stack, so I'm more likely to leave this WG alone if it insists
on its current approach than to spend my precious time on fighting it.
Nor can I or do I speak for anyone else.  But I can imagine someone
taking a scorched earth, spiteful approach, and if they do, you best bet
I'll be eating popcorn and cheering them along.

Nico

[*] No has one said "bleep off", but that's clearly the message being
    sent, and it's certainly the message that's been received.