Re: [kitten] [Curdle] I-D Action: draft-ietf-curdle-des-des-des-die-die-die-03.txt

[Benjamin Kaduk <[e-mail]>]

Hi Martin,

On Fri, Jun 23, 2017 at 02:03:41PM +0200, Martin Rex wrote:
> Benjamin Kaduk wrote:
> > 
> > It sounds like you are asking for the addition of some text along
> > the lines of:
> > 
> >   Software support is only a bare minimum requirement for deprecating
> >   RC4 enctypes; there may be additional logistical considerations
> >   involved such as provisioning AES keys for all principals and
> >   updating software configuration to enable AES and disable deprecated
> >   encryption types.
> > 
> > Is that something you are asking for?
> 
> Yes, thank your.  This sounds good to me.  I consider it even more
> helpful than the reference to particular versions of particular
> OpenSource Kerberos implementations, because this is a characteristic
> that is sort-of implied by how kerberos-enctypes keys are created
> (derived by string2key) and probably affect all implementations of
> Kerberos, yet it is non-obvious to consumers of the technology.

Thank you for clarifying your comment into a request.

> 
> There is a substantial difference between cipher suites in TLS, where
> key length, strength and algorithm for the symmetric crypto is mostly
> irrelevant to the (PKI) credentials, and where using new TLS cipher suites
> and deprecating old TLS cipher suites does not have a rekeying requirement.

To some extent this is inherent in Kerberos's use of symmetric crypto for
authentication, as opposed to TLS which uses asymmetric crypto for
authentication and switches to symmetric crypto for efficiency for
bulk data transfer.


(Jeffrey Altman wrote:)
% In my opinion, such text is inappropriate for an RFC.  The deprecation
% of the encryption type is a protocol action.  The RFC is not guidance
% for system administrators.  Such guidance should come from the protocol
% implementations.
%
% As such I believe the addition of text similar to the above is
% unnecessary for publication.

> 
> I do believe that it is very appropriate to provide such kind of a
> guidance in an RFC, so that it this recommendation for deprecation
> becomes more comprehensible and the trade-offs clearer to mere consumers
> of the Kerberos technology, readers that aren't Kerberos protocol experts
> and senior Kerberos implementers.

In general I tend to hew more to Jeffrey's track that protocol specifications
should limit themseles to protocol-level work.  I could see some grounds
for an exception here, though, in that the deployment difficulties are
inherent to any Kerberos deployment that follows best practice of not storing
user passwords (only derived keys).

Given Jeffrey's reasoning, I do not think my above "proposed text"
(to get clarification from Martin) should be used as-is; if we do want
to provide the clarification that Martin wants, I would want to rephrase
things somewhat.  But, it still seems unclear where the WG consensus lies
on the question of including any guidance at all, here.  Can others
please weigh in?


> When making admins sufficiently aware of predictable interop-problems,
> we may actually see more administrative deprecation of weak Kerberos
> enctypes than leaving them in the dark, and it helps reducing the amount
> of stumped users, helpdesks and admins.

Admins are more likely to read software-provided documentation than
protocol specs; this argument seems speculative to me.

-Ben