On Wed, Apr 10, 2024 at 1:32 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 4/9/24 14:14, John Scudder wrote:
The odd thing is that the I-D submission process was originally intended to be very low overhead, before XML and the lawyers and even the tools got in the way.
Keith
As was the Request For Comments publication...
Registration of code points raises three separable cases:
1) Where the code space is constrained by necessity.
Many of the systems at the narrow waist have code points represented by integers and are thus limited to what will fit into 16, 8 or 4 bits. These require careful conservation for the obvious reason they are scarce. But even in these cases, the role of the IETF is that of a steward, if people want to innovate and there is a sufficiently large constituency supporting the proposal, people can write their own code points.
Case in point, if someone with the requisite opinion and keyboard were to decide they wanted to do IPv7, there is nothing IETF can do to stop them, but the experiment is unlikely to have widespread consequences. If on the other hand the EU or China were to decide they wanted to drop a billion dollars on a new network protocol, control of the version field registry is not going to stop them.
2) Registration of cryptographic protocols and
3) Registration of everything else.
Remember 'permissionless innovation'? If code points are being used as control points, we are violating the original mission statement for the Internet. When I tried to register the SRV code points for SAML, there was no registry and no process for doing it. So the SAML code points are the ones I made up.
Having a published specification is good. But the only really essential thing with a code point is that it be unambiguous and the next most important is that it be unique. Having 'AES' map to two different things would be very bad. Having 'AES' and 'Rijndael' is icky but tolerable.
[With CAA, 'expert review' sometimes comes down to sad reflection on the unfortunate fact that DNS does not work in quite the way we would want it to.]
The original post is about registration of a proposed SSH scheme and this raises the real issue of there being no way that IETF or any other organization can do an adequate job of evaluating the security of every cryptographic algorithm someone with opinion and keyboard walks in off the street with.
The problem of giving people registration in IETF code space is that it creates the perception that the algorithms are IETF endorsed. And the IETF is simply not set up to do that, not least because IETF process is fire and forget, there is no ongoing review like there is for IEEE or ANSI.
There are cryptographers who have come to IETF meetings but this is not the place where we consider the security of cryptographic algorithms. The process the industry has come up with is to pester NIST to hold global competitions and bring a couple of dozen teams of cryptographers to work on a particular need hunger games style.
And here is the kicker, there is absolutely no 'expert' on cryptographic algorithms or number theory or anything else who can tell you that an algorithm is secure. All they can tell us is which algorithms are insecure and what the best known attack is against anything else.
This is why I have been recommending IETF get out of the business of endorsing cryptographic algorithms beyond specifying the algorithms REQUIRED for interoperation. And even there, the algorithms REQUIRED to implement JSON Signature (say) might well be different from those REQUIRED to implement an algorithm using JSON Signature written a decade later.
Here is how I would get out of the business of endorsing algorithms:
1) Create a new registry for 'Data Transformation' algorithms, make it an open registry. Create slots for a description, text tag, an OID and a URI, all optional.
2) Create a rule that all new registrations for code points for PKIX, JOSE, etc. etc. MUST NOT conflict with the registrations in the DT registry.
3) Thats it.
The sleight of hand here is that anyone wanting to use their own 'BreakingBad' cipher can ensure that there is a unique code point for SSH, OpenPGP, etc. etc. by simply creating the Data Transformation registration but that does not entail any form of endorsement by IETF because the DT registry will contain things like compression algorithms, etc.
