Re: Comments on Mandatory Ciphers and a Proposal

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Ned and all,

Ned Smith wrote:
> 
> At 03:06 PM 7/25/97 -0400, Keith Moore wrote:
> >> At 5:51 PM -0700 7/24/97, Keith Moore wrote:
> >> >> Applications have to be able to
> >> >> say that they are "conformant" to the TLS protocol even when they
> provide
> >> >> the result "we can't agree on a mutual security requirement". (Which,
> BTW,
> >> >> I think means they are sufficiently interoperable.)
> >> >
> >> >If a customer buys a POP+TLS client from one vendor and a POP+TLS
> >> >server from another vendor, and they won't talk to each other because
> >> >they don't each support a TLS ciphersuites of sufficient
> >> >strength... somehow I doubt he would agree that they are sufficiently
> >> >interoperable.
> >>
> >> However, your example in this arguement is bad -- I believe that POP+TLS
> >> should be define a ciphersuite requirement. I am only saying that TLS, bare
> >> of any protocol (i.e. not very useful by itself) should not define any
> >> ciphersuite requirements other than SHOULD recommendations that the
> >> POP+TLS/SMTP+TLS/HTTP+TLS may decide to make MUSTs.
> >
> >The problem is that it's so easy to combine TLS with any protocol that
> >uses a single TCP stream, that people will do it in the absence of any
> >external specification.  We've seen this several times already with
> >SSL.  Of course, this is a "feature", and in most respects it's a nice
> >one.
> >
> >But vendors don't want to wait on a specification, they want to ship
> >product ASAP...ideally, before their competitors do.  So they'll ship
> >FOO with TLS before there's a specification for doing so.  And their
> >marketers will claim compliance with TLS.  And the customers will buy
> >FOO clients and servers that claim compliance with TLS and find that
> >they don't interoperate at all, or the implementations won't
> >interoperate with adequate levels of security.
> >
> >So we need to define what "compliance with TLS" means, including
> >mandantory ciphersuites that are adequate for most purposes.
> >
> >Keith
> 
> Keith,
> Your concern for keeping over eager marketers in check is certainly
> appreciated by all. However, it strikes me as being a little like the tail
> wagging the dog. The status of any draft in the IETF is public information.
> Any potential customer is able to cross check the progress of a standard
> without trusting the  over eager marketer.
> 
> (It probably goes without saying.) But this doesn't lessen the need for
> standards to move quickly - it just shouldn't be a substitute for designing
> a protocol based on technical merit.

  My point exactly on an earlier post here.  It appears to me that a
movment
is afoot to substitute political language within the standard to
substitute
for good design.  This is a bad standard, and also not necessary.  It
will never stand up in the commercial market if done in this manner.  
Distrust will begin to creep into the IETF and IESG by the industry and
commercial sector very surely if this is the persute.
> 
> Your last point about mandating a ciphersuite "suitable" for most purposes
> is intuitive but also subjective. No matter what the WG chooses it will be
> the wrong choice. The current architecture of TLS is sensitive to the need
> to separate policy from mechanism. And the mechanism allows the parties to
> negotiate the policy.

  Partialy correct here I think.  BUt again one must be careful that
those
parties and the negotiations are not a substitute for good ddesign/Arch.
if don in that manner than you have not accomplished developing a good
sound standard.
> 
> Regards,
> Ned
> Ned Smith                 Intel Architecture Labs
> JF2-74  2111 N.E. 25th Ave.  Hillsboro, OR. 97124
> Ph: 503.264.2692 Fax: x1805  Mailto:nsmith@xxxxxxxxxxxxxxx
> Http://www.intel.com/ial/security/index.htm
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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