Re: [kitten] An idea to go beyond 32 flags in draft-ietf-kitten-kerberos-iana-registries-03

[Benjamin Kaduk <[e-mail]>]

[sorry for the extra copy, Rick; I had to enter kitten manually since
reply-all tried to send the wrong place, and then I typo'd it]

Hi Rick,

Greg has already covered some of this, but I also wanted to say a few
things.

On Wed, 13 Apr 2016, Rick van Rein wrote:

> Hello Tom / Kitten,
>
> Last week the Kerberos IANA registries draft popped up again.  I find
> the general useful, but I feel strong objections against constraining
> "Named Bit Assignments" to the 0..31 range.  I mentioned this before,
> but now also see a way out.  My proposal is the replacement text at the
> end of this email.
>
> My reasons for my objection + alternative are
>
>  (1) specifications should not follow implementations, and certainly not
> confirm bad ones;

A motto of the IETF says (in part), "we believe in rough consensus and
running code".  In practice, this means that weight is given to actual
existing code, and this point is not really true -- IETF specifications
frequently do follow implementations, even bad ones, since that's the
route to getting things deployed.  A perfect spec that is not implemented
is not particularly useful...

>  (2) limiting to 32 named bits will confirm this lowest common
> denominator and increase the number of flawed implementations;
>  (3) after confirming a 32-bit limit, we have cut off any chance of
> growing beyond this;

This is also not exactly true; a future standards-track document is
permitted to change the registry specification and allow a larger number
of bits to be used.  And implementations still have to be prepared to
decode larger bitstrings with a conformant ASN.1 decoder -- just reading
bits off the wire into a uint32 would lead to software vulnerabilities.
Perhaps it might confirm it in those libraries' API layer, but that does
not seem to be a materially worse situation than what we have at present.

>  (4) software that is incapable of being updated is a security problem,
> not something that a spec should seek to confirm;

I'm not sure what is suggesting that software is fully *incapable* of
being updated; rather that making updates in this case would be a lot of
effort and require churn in the user interface.  Seeking to avoid having
to go through all that effort until it is fully necessary is reasonable to
many people, though reasonable people could certainly disagree.

>  (5) we currently cannot supply bits for experimental/private use, for
> instance for development purposes; developers end up stealing bits and
> the registry becomes an administration of such sins.

This is true, and is somewhat unfortunate.  On the other hand (as Greg
notes), there are usually other places in the protocol where similar
information could be placed for experimental purposes.  That is not a
particularly compelling argument, of course, but in the balance, to me,
the 32-bit limitation still makes sense for now.

-Ben