Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Keith and all,

  I only have a few comments here, so I will not be Monty pythonish
i hope...  >;)

Keith Moore wrote:
> 
> > >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.
> 
> None of these quite describes the meaning I have above.
> 
> IETF doesn't claim to dictate anyone's security policy.

  But There is language that will influence it.  Not that this is
bad, it is not in my opinion.  But should we do so?
> 
> IETF can and does make recommendations about security policies.  Every
> RFC has a security considerations section for this purpose.

  Exactly.  And that is subtil influence on companies security
policy or standards.  Is this proper?  i don't know myself.
> 
> IETF also can and does define what it means to say that a implementation
> conforms to protocol FOO or RFC XXXX.   This includes specifying
> minimum requirements to ensure that a conforming implementation will
> interoperate with other conforming implementations.

  As it should be.
> 
> So *especially* for a protocol which claims to provide security, IETF can
> specify that a conforming implementation of that protocol must be able
> to provide at least a particular level of security when interoperating
> with other products which also claim conformance to that protocol.

  But not all applications that may use TLS are going to be protocols
necessarly.
> 
> None of these things are intended to dictate anyone's security policy.
> All of them are intended to make it easier for users of IETF protocols
> to choose an appropriate security policy for their needs.

  Agreed in this context.  But there is still INFLUENCE being used
here, that I am not sure in proper.  But I am again not sure
that it isn't either.  
> 
> Just because a conforming implementation of some TLS-enabled
> protocol is expected to implement particular ciphersuites, doesn't
> mean that any user or service provider is expected to allow them
> in their security policy.  But if security that is adequate for
> most applications is part of the standard, then it will be easier
> for many users to choose a security policy that is adequate for their
> needs.

  I must agree here.  It just seems that there is subtil pressure
being applied that may or may not be necessary.  
> 
> > 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.
> 
> I suppose it depends on how you view the market.  I can imagine that
> people who buy "security products" want to select exactly which
> TLS ciphersuites their security policy will allow, and then buy
> only security products that support those ciphersuites.
> 
> Mass market applications aren't sold that way.  The web browsers I
> see have two grades of security: "international" and "US", and vendors
> complain that this is too many.  I could decide that my security
> policy for POP requires 2048 bit RSA and IDEA, but that doesn't mean
> I could afford to buy POP clients that would support that ciphersuite.
> I have to take whatever the vendors want to sell me.  Even if I could
> buy a POP client with RSA2048 and IDEA, it might lack other non-security
> features that I need.
> 
> And not only will most users not be able to implement a particular
> security policy, most users have neither the desire nor the expertise
> to do so if they could.  That doesn't mean that they don't want
> or need security, they just don't want to make fine-grained decisions.

  Well this is a problem for those companies to solve, not the IETF.
I believe it is foolish not to have the expertease on board not to
be able to make these type of fine-grained decisions.  Bad policy
and bad managment practice.
> 
> But if all standard TLS+POP clients and servers support a single
> ciphersuite that's adequate for most needs, then for most people,
> such decisions become easy: just buy a TLS+POP client and server
> that conform to the standard.

  As long as those standards meet the strongest security avalible
at the time and are flexible enough to inhance that security as
new better security capabilities come along.
> 
> After all, the very reason we have standards is to narrow the
> number of choices we have to make to acheive a particular result.

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