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

Hi,

Thank you for the discussion. It seems that overall the current draft has a
reached consensus. Are we ready to move the draft forward or do we need any
additional discussions ? If you think more discussion is needed please let
us know as soon as possible. Unless concerns are raised, I am planning to
set  the shepherd write up early next week.

Regards,
Daniel

On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

> 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
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>