Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Keith,

Keith Moore wrote:
> 
> > > > >  There will surely be uses of TLS for
> > > > > which 3DES isn't considered to be of sufficient strength, and there
> > > > > may even be uses of TLS for which DES40 is considered adequate.  So
> > > > > there's no problem with a particular application protocol using TLS as
> > > > > a component, and specifying its own mandantory ciphersuites, and we
> > > > > should expect this from time to time.
> > > >
> > > >   I agree.  However this argument does not support a requirnment for
> > > > a MANDITORY cipher suite as part of the spec.
> > >
> > > Nope.  It's okay for a feature to be a SHOULD if failure to implement
> > > that feature doesn't compromise interoperability.
> >
> >   That decision should be left up to those implimentors doint the
> > inplimentation.
> 
> It *is* left up to the implementor.  But if the implementor doesn't
> include the mandantory ciphersuites specified for that application,
> then the implementation isn't compliant with the specification.
> Period.

  Ok.  I guess I wasn't very clear on my comment here, so I will try to
clear it up a bit.  NO application SHOULD be PREDICATED to ANY
particular
cipher suite.  That is a choice situation, not a MANDITORY one. 

  The reason is pretty simple really.  If an implimentor does not
choose to use teh cipher suite that is stated as MANDITORY, than
he/she should have a choice as to which cipher suites they desire.
And not be required to impliment ANY MANDITORY cipher suite at all.
This is too limiting and not benificial to interoperability at all
Period.
> 
> > > It's fine for the general TLS spec to have one set of mandantory
> > > ciphersuites, to be used with most applications, and for any specific
> > > application to have its own set of mandantory ciphersuites.  But in
> > > either case there MUST be a mandantory ciphersuite for every
> > > standards-track TLS-aware application.
> >
> >   Why?
> 
> So that any two implementations that are written to conform to the
> spec, will interoperate.  As long as this is not the case for TLS,
> the TLS specification is incomplete, and will not go forward on
> the standards track.

  I don't see this as necessary as part of the standards track.  JeffS,
doesn't either and stated such.  It seems to me that this by definition
limits interoperability rather than provides for it.
> 
> > > If several TLS-aware applications run on a single host, they should be
> > > able to share a single TLS library.  That TLS library needs to have
> > > enough ciphersuites to support the minimum requirements of all those
> > > applications.
> >
> >   I agree.  Anain this does not predicate a MANDITORY cipher suite
> > to be used for any application.
> 
> Every standards-track application protocol must be completely specified.
> If the application needs security, and uses TLS, there must be
> mandantory ciphersuites specified for that application.  The only
> question remaining is whether TLS itself needs to specify mandantory
> ciphersuites, and allow an application protocol to simply reference
> the mandantory ciphersuites chosen by TLS.

  This is not what I understand the IESG statment to say.  SO I can now
see where we have some diffrences.
> 
> The IESG has determined that TLS does indeed need to specify
> mandantory ciphersuites, even though specific applications may
> choose a different set.
> 
> > > It's fine with me if the 40bit ciphersuites are in the "SHOULD
> > > implement" category, as long as the DH/DSS/3DES ciphersuit is "MUST
> > > implement".
> >
> >   Not ture completly.  if you add the DH/DSS/3DES ciphersuite as one
> > of the should impliment group, than the implimentor can decide depending
> > on the needs which of the cipher suites (possibly multipul), to be
> > implimented or a selection wizard could be used for multipul
> > applications to accomplish this gole without the need or requirnment
> > for a MANDITORY cipher suite to be implimented.
> 
> Nope.  That doesn't satisfy the interoperability requirement.

  SUre does.  And if you think it doesn't, why doesn't it?
> 
> Keith

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1@xxxxxxxxxxxxx