Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Keith,

Keith Moore wrote:
> 
> > > > > 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.
> 
> I'm not sure what you mean here, but I'll restate myself more clearly:
> 
> Every application that (a) needs security and (b) uses TLS for security
> must define a mandantory set of ciphersuites.  Otherwise, we could have
> a situation where two implementations didn't have a common ciphersuite
> that was adequate to the needs of the application.

  Again I would say this should be a CHOICE not a manditory ciphersuite.
That CHOICE should be made by the implimentor, not predicated by any
spec.  No application should be locked to any particular ciphersuite,
rather there should be a choice of cyphersuites avalible depending on
the level of security that user or group needs or desires, not waht a
spec
my wish to dictate.  If the ciphersuite is a weak one, lets say, than
that
may not be the CHOICE of the implimentor to use.  Personally I don't see
anyreason why cipher translation cannot be done here.  We do it 
in our Interface facility (MLPI) for instance.  But if that is not
desired as part of the TLS spec, ok.  However MANDITORY ciphersuite,
requirnment is still not flexible enough for multipul types of
implimentations and applications.

> 
> The definition of mandantory ciphersuites for a particular application
> can either be by reference to the TLS spec, or by specifying a different
> set of ciphersuites specifically for that application.

  Well than this is not MANDITORY.  This fits the SHOULD catagory.
> 
> Note that an application may have certain minimum security needs,
> and a user of an application may have different security needs.
> To be compliant with the spec, any implementation of that application
> must be able to provide the minimum security needs.  But the "user"
> (say, the administrator of a web server) should be able to adjust
> the application according to the user's needs -- either to increase
> or decrease the level of security required.

  I agree completely with this statment in its entirity.  And now I am
baffeled by your insistance of MANDITORY ciphersuites as part of the
spec
for implimentation perposes.  Possibly I have misunderstood what you
have been saying?  
> 
> >   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.
> 
> What you've said in essense if that if someone chooses, they should
> be able to make a choice.  That's like saying X is X.

  No not exactly.  I am saying that if they do not prefer or their
needs for any application that may use TLS for security, that they can
CHOOSE which ciphersuites the feel are necesssary for those applications
that will be using TLS as a security facility.
> 
> > And not be required to impliment ANY MANDITORY cipher suite at all.
> > This is too limiting and not benificial to interoperability at all
> > Period.
> 
> You haven't said a single thing in support of your argument.

  I have said it all several times, hence I left those long winded
arguments out in this posting.
> 
> > > 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.
> 
> Ultimately, IESG is responsible for making such decisions.
> IESG did deem it necessary to have mandantory ciphersuites.

  Hummmm?  This was not my understanding originaly from JeffS's 
posting.  In fact quite the contrary.
> 
> Some have argued that the market will force TLS implementations to
> be interoperable.   But this is also a circular argument.
> No product that claims to implement TLS, but doesn't interoperate
> with other TLS implementations, is likely to stay around for very long.

  What is stopping interoperability form happening?  Your argument here
is circular.

> Left to itself, the market forces interoperability by making it so
> difficult for anyone to implement a product, that it's out of reach
> of anyone without substantial resources.

  What???  Not at all!  The TLS spec shuld offer a list of SHOULD
ciphersuites
and the ability to add additional ones as they become avalible.
> 
> IETF doesn't work that way.  IETF acheives interoperability by writing
> clear specifications, making them publically available, and whenever
> possible and appropriate, using technology that is available to anyone.
> IETF's goal is not just interoperability, it also wants a level playing
> field.

  I agree with this approach.  And have stated nothing contrary to it.
> 
> > It seems to me that this by definition
> > limits interoperability rather than provides for it.
> 
> I suppose it depends on how you define interoperability.

  I suppose it does.  I define it as the ability to interoperate
with diffrent applications in a seamless and easly implimentable
method.
> 
> I want to make it as easy as possible to build a TLS implementation,
> such that any two TLS implementations provide adequate security for the
> services that want to use it -- which is to say, most of the applications
> level protocols we have today.

  I do as well. With what you seem to have said reguarding requiring
MANDITORY ciphersuites for implimentation for applications you limit
this ability by defination.
> 
> If two TLS implementations can't agree on a common ciphersuite,
> that's not what I would call interoperation.  If two TLS implementations
> can't negotiate a ciphersuite that provides adequate security for the
> application, that's not interoperation either.

  I don't agree with your first statment compleatly.  I do with the
second.
The first statment basicly is saying that you cannot do ciphersuite 
translation.  We have already done this, it works!  So reguardles of
which ciphersuite you may choose, and another user on the other end
uses a diffrent ciphersuite, really doesn't matter, our translation
routines
will handle that problem currently with known ciphers.  And many private
ones as well.  But this is besides your point and really for another
discussion.   Your assertion that manditory ciphersuites May in some
cases provide for interoperability.  In some cases as a fall back use
of that ciphersuite.  But certianly not in all will Manditory
ciphersuites
provide for interoperability.  
> 
> > > 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.
> 
> I'm speaking for myself here, not IESG.  But this is how I see things,
> and it does reflect how I will cast my ballot as an IESG member.
> I'm willing to consider counter-arguments, but so far I haven't seen
> any argument that is even close to persuasive.

  Well I suppose I have failed in my arguments.  That is unfortunate.
But to me of no matter.  By requiring MANDITORY ciphersuites you will
only
inhance the sales potential of our product to augment TLS anyway, so I
or we cannot loose in whatever dicision you or the IESG makes.
> 
> > > > > 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?
> 
> A spec for protocol FOO doesn't require any mandantory ciphersuites.
> Implementor A of FOO chooses to implement ciphersuites P, Q, and R.
> Implementor B of FOO chooses to implement ciphersuites W, X, and Y.
> Both implementations follow the FOO specs to the letter, but they
> can't interoperate.

  Not true!  If FOO can translate ciphersuites, this becomes a moot
consideration.
> 
> 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