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

[Benjamin Kaduk <[e-mail]>]

On Thu, Jul 06, 2017 at 12:01:49PM -0400, Daniel Migault wrote:
> 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.

(Intentionally retaining quoted text below.)

I think we're ready to move the draft forward (as-is).

Having reviewed the extra comments, as well as the current text,
I don't think that there is a need to add something along the lines
of what Martin had proposed.  If I was going to add anything, it would
be along the lines of:

  Administrators are additionally expected to be capable of designing rollout       
  plans that minimize disruption, provisioning keys with the new enctypes before    
  enabling new enctypes in configuration.                                           

(at the end of section 5.4).  But it's not clear that this is really adding
value.

-Ben


> On Sun, Jun 25, 2017 at 10:11 PM, Benjamin Kaduk <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/curdle
> >