Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Keith,

Keith Moore wrote:
> 
> > > 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.
> 
> You've said nothing to convince me that this could be done in a way
> that guarantees interoperability for compliant implementations.

  I can understand you possition here.  But I have given several 
reasons as otherws have on this list as to why, so I see no reason
to use up bandwidth is repeating them again.  Please review the
other responses on this thread.
> 
> > 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.
> 
> The application isn't locked into a particular ciphersuite.  It has to
> implement the MUST implement set, but it MAY implement other
> ciphersuites.  Similarly, the user MAY disable use of the mandantory
> ciphersuite, and MAY allow use of ciphersuites other than those
> required by the specification.

  Hummm?  ok.  But this really isn't what I viewed your comments
previously regarding MANDITORY.  And in effect really isn't.
> 
> But for the application to comply with the specification, it MUST
> allow the user to enable the "must implement" ciphersuites.

  Argument in a circle again.  Not convencing.
> 
> > > 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.
> 
> "SHOULD implement" is not appropriate here, because it would allow an
> implementation that doesn't interoperate to claim compliance with the
> specification.

  Absolutely not so.
> 
> > > 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?
> 
> Perhaps.  But I don't know how else to explain it.
> 
> > > 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.
> 
> Someone who designs an writes his own application can choose whatever
> ciphersuites he wants to, according to what he thinks is appropriate
> for that application.  The TLS specification shouldn't forbid that.

  Right!  Nor should compliance to the standard.
> 
> But Internet standard application protocols that use TLS are going to
> need "MUST implement" ciphersuites.

  Again a circle.
> 
> > > 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.
> 
> Read RFC 2026 for a full description of the standards process.
> 
> > > 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.
> 
> This argument is starting to read like a Monty Python sketch, so I'm
> going to stop responding.  I've already stated my case.

  Very well.  Though I still do not see you argument for MANDITORY
Ciphersuites.
> 
> As to "ciphersuite translation", whatever that is:

  It is the ability of using two seperate ciphersuites in order to
interoperate.
> 
> A) If you use an inadequate ciphersuite over an unsecured link,
>    no amount of translation is going to make that ciphersuite
>    any stronger.

  On one side yes, but not necessarly on the other.
> 
> B) Translating gateways are evil.

  This sounds nearly cultest of nature.  ???
> 
> 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