Re: Comments on Mandatory Ciphers and a Proposal

[Keith Moore <moore@xxxxxxxxxx>]

> > 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.


> 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.

But for the application to comply with the specification, it MUST
allow the user to enable the "must implement" ciphersuites.



> > 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.


> > 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.

But Internet standard application protocols that use TLS are going to
need "MUST implement" ciphersuites.


> > 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.


As to "ciphersuite translation", whatever that is:

A) If you use an inadequate ciphersuite over an unsecured link, 
   no amount of translation is going to make that ciphersuite 
   any stronger.

B) Translating gateways are evil.

Keith