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

[Greg Hudson <[e-mail]>]

On 04/13/2016 04:32 AM, Rick van Rein wrote:
>  (1) specifications should not follow implementations, and certainly not
> confirm bad ones;
>  (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;
>  (4) software that is incapable of being updated is a security problem,
> not something that a spec should seek to confirm;
>  (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.

(There is a brief earlier conversation here:
http://www.ietf.org/mail-archive/web/kitten/current/msg04761.html )

(1) IETF specifications often follow implementations and take into
account their limitations.  The desirable outcome of IETF work is
practical interoperability, not strict adherence to a waterfall model.
As examples, we recently re-issued RFC 4402 as RFC 7802 because
implementations screwed up the PRF count, and we are in the process of
re-issuing RFC 6112 because an implementation screwed up the case of a
key-derivation pepper input.

(2) Heimdal and MIT krb5 both use 32-bit values for the flags fields in
RFC 4120, and use those fields in public library API structures.
(Shishi uses 32-bit flag values but I don't know anything about its
library APIs; I don't think Microsoft has a Kerberos library API.)
There isn't much danger of increasing the number of implementations with
this limitation; the damage is already done.

(3) Applying this rule to the registry now does not preclude changing it
later.  The same high implementation costs would apply regardless of how
the current registry rules are set.

(4) I find this argument really hyperbolic in several respects.  Most
importantly, there are lots of ways to extend RFC 4120 beyond adding
flag values.  "Flags" are just a compressed representation of boolean
values; there are typically other, less efficient ways to add boolean
values to the surrounding ASN.1 sequence, such as authorization-data in
Ticket or padata in KDC-REQ.

(5) This is a real cost, though I can't think of a historical case where
an implementation has squatted on an RFC 4120 flag value.  It needs to
be weighed against the implementation cost of extending flag values.

> The suggestion below puts some suggestive pressure towards proper
> implementation, by hinting at a future with bits beyond 32, also for
> experimental/private use.

I don't think this suggestion has any practical benefit.  Anyone who
registers a flag value above 35 with a non-standards-track specification
would find themselves quite disappointed in their ability to use this
flag in any of the widely used krb5 implementations.

> Note that allowing more bits than anticipated is purely a parsing
> matter; any implementation has a limited number of flags that it can
> understand, and so the only requirement is to be able to parse DER
> structures with more bits than understood [...]

In some cases, implementations also need to be able to re-encode flag
values (particularly TicketFlags) without losing information.  For
instance, RFC 7751 section 4 requires KDCs to encode an EncTicketPart,
which contains a TicketFlags, for the ticket surrounding a CAMMAC.