Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Dan and all,

Dan Simon wrote:
> 
> Comment below....
> 
> > From: dpkemp@xxxxxxxxxxxxxx [SMTP:dpkemp@xxxxxxxxxxxxxx]
> >
> > Two methods of achieving clean reuse have been proposed:
> >
> > 1) Have the Technical Standard for TLS and the Applicability Statement
> >    for particular ciphersuites appear in separate RFCs, and
> >
> > 2) Allow the TLS Applicability Statement be reused without overriding
> > it
> >    by designating the preferred ciphersuites as SHOULDs instead of
> > MUSTs.
> >
> > Most of the TLS working group is in favor of option 2 (although I
> > would
> > like to hear the opinions of those who haven't chimed in yet - Dan
> > Simon,
> > Tatu, ekr, eay (who probably isn't reading email while on vacation
> > :-),
> > Paul Hoffman, etc.).
> >
> >
> In case my previous posting to this list didn't make it clear, I agree
> wholeheartedly with the majority that option 2 is preferable.  The whole
> idea of interoperability taking precedence over everything else may make
> sense for other types of protocol, which exist only to make
> communication feasible.  Security protocols, though, also exist to make
> certain kinds of communication *infeasible*.  Sometimes, two people
> should *not* be able to talk to each other, if their security policies
> are incompatible.  I find it sad that those at the IESG who are
> responsible for security issues don't understand this basic point.

  Well finnaly a voice of reason.  

  I am hartened to see that at least you Dan seem to be on the same 
rung of this laddre as I am.  Security protcols are somewhat diffrent
to be sure.  I would add one other thing that I have added befor.
"THERE ARE NO POLITICAL SOLUTIONS TO TECHNICAL PROBLEMS".  It is
IMHO that there are NO processes or Policies that should or indeed
can, predicate how any software SHOULD be developed in and of
themselves.
This is not to say that processes cannot help in that development, but
only if some basic sound software engeneering principals are employed,
and that those principals are indeed subject to change at any time or
to meet a "SPECIAL" situation such as TLS.
> 
> As for option 1, I don't consider particular applications to have
> security requirements any more than particular protocols do.  *Users*
> have security requirements, and applications and protocols exist to meet
> those requirements.  If a group of vendors and customers come to agree
> that triple-DES is not secure enough for them, and that IDEA or Blowfish
> or RC5 or whatever is more trustworthy, then those people are as
> entitled to the benefits of the IETF standards process as anyone with a
> DES-trusting security policy.  For the IETF to declare, in effect, that
> they only care to work with people who are satisfied with triple-DES for
> some application or other (let alone for all applications) is both
> short-sighted (since their disdain for alternate cryptographic choices
> may one day turn out in retrospect to have been misplaced) and
> narrow-minded.

  How very true.
> 
>                                 Daniel Simon
>                                 Cryptographer, Microsoft Corp.
>                                 (dansimon@xxxxxxxxxxxxx)

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