Re: Comments on Mandatory Ciphers and a Proposal

[Chris Newman <chris+ietf-tls@xxxxxxxxxxxx>]

On Tue, 22 Jul 1997, Tom Weinstein wrote:
> >         Mandatory to implement means that a protocol implementor MUST
> > implement the mandatory portion of the specification. It does *NOT*
> > require that end-users use that portion. In other words we are *not*
> > demanding that all users of TLS use 3DES (or DES), we are just saying
> > that implementers MUST give them the option to in compliant products.
> 
> Which is exactly the problem.  If it's mandatory to implement, it gives
> protocol designers no flexibility as to the encryption choices that are
> right for their applications.  This is why I support declaring some
> small number of cipher suites SHOULD, and relying on implementors to do the
> right thing.

Why not just put at the top of the spec: "Ignore anything you want in this
spec, and we'll trust that you make the right decisions so it works."?

Seriously, there's nothing stopping a standards track profile for a
particular application from changing the rules as appropriate, so I
consider this a groundless argument.

> > Have: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA *and*
> >       TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> 
> Per the Danvers Doctrine, I don't like any export crippled cipher being
> a MUST.  Since any exportable implementation is going to be non-compliant
> anyway, I don't see that there's a compelling reason to include one.

I like Jeff's proposal because it reflects the real world without
compromising the spirit of the Danvers Doctrine.  The vast majority of
deployed SSL clients use 40-bit keys and I have no reason to believe TLS
will be much different.  Jeff's compromise allows the export-crippled
non-compliant versions to interoperate with compliant implementations to
the extent of getting 40-bit key encryption.  That's still better than no
encryption.

		- Chris