Re: Comments on Mandatory Ciphers and a Proposal

[Tim Dierks <timd@xxxxxxxxxxxxx>]

At 5:01 PM -0400 7/24/97, Keith Moore wrote:
>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.
>
>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.
>
>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.

Could you define "application" as you use it here and as we use it in this
discussion? For your convenience, I supply some possible alternatives:

  A) An application is a protocol which uses TLS. HTTPS is an application.
  B) An application is a particular implementation of a protocol which uses
TLS. The Netscape Commerce Server is an application.
  C) An application is a particular service (uses an implementation and a
protocol and TLS). The server which I connect to to do Internet banking
with my bank is an application.

What it appears to me that you're saying is that we can define MUST suites,
but that decision can be modified at the "application" level, but that the
"application" level imposes that decision as mandatory to all downstream
customers. (That is, if application meant "A", the ciphers mandated there
would be mandatory for "B" and "C". If application meant "B", that decision
would only apply to "C".)

Unless you mean C, I'm in strong disagreement. For people who control "A"
and "B" to impose security decisions on people downstream of them is
unthinkable. To believe that the TLS working group, the HTTPS working group
(or other specification group or mechanism), or software vendors can be
expected to define security policies for the wide array of users who depend
on them is not only naive, it demonstrates a basic lack of understanding of
the needs of security in general and the security marketplace in specific.

 - Tim

Tim Dierks - timd@xxxxxxxxxxxxx - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite