Re: Comments on Mandatory Ciphers and a Proposal

[tomw@xxxxxxxxxxxx (Tom Weinstein)]

Jeffrey I. Schiller wrote:
>
>         Let me make some comments on what it means to be "mandatory to
> implement." I have been reading the list archive (though I have yet to
> read every message on this subject) and have found some common
> misconceptions.
> 
> o The purpose of mandatory to implement algorithms/protocols is to
>   ensure that two independently implemented versions of an IETF protocol
>   specification will be able to communicate with each other.
> 
> o The "Danvers Doctrine" (I like that name) simply stated that the
>   IETF should standardize on the best security technology and should not
>   "dumb down" a version because of some country's export control
>   rules. If a company believes that it is being hurt in the market place
>   by its countries export control laws, it should take that subject up
>   with its government and not demand that the IETF change our standards
>   to accommodate that government.
> 
>         Although I have not done a scientific study, it appears to be
> that this doctrine is supported overwhelmingly by USERS of the
> technology. Heck, people want the best stuff they can. It is less
> supported by implementers as they are the ones who feel the market
> pressure from foreign competitors.

I certainly believe that the Danvers Doctrine is a good idea, and I
support it fully.  If the IETF standardizes TLS in such a way that my
implementation is at a competetive disadvantage to overseas
implementations, then that just gives us extra amunition to argue for
the
removal of export restrictions.  I'm farsighted enough (and optimistic
enough) to see that the long term benefits of that outweigh any short
term
costs due to unequal competition.  However, my argument against
mandatory
cipher suites has nothing to do with export regulations.

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

>         I would be willing to buy into the following compromise (of
> course before this would be approved by the IESG, the rest of the IESG
> would have to buy in as well):
> 
> Have: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA *and*
>       TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
> 
> as mandatory (along with the anonymous variants as well, for a total
> of four cipher suite in all. In fact this is the same set that Tim
> Dierks proposes as "SHOULDs" in his message).

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.

>         In this fashion a U.S. company (assuming that 3DES is not
> exportable) would *not* be able to distribute broadly overseas a fully
> compliant version of TLS (sorry). However if they only remove 3DES but
> leave DES40 available, they will be able to interoperate with
> compliant versions because the compliant versions will still have to
> support DES40. Of course the compliant version's user may decide to
> inhibit connections using that cipher suite, but it will be the
> end-user's choice.
> 
>         What do people think? (Note: I can only devote a limited
> bandwidth to this discussion...).

I still believe that the inclusion of SHOULD cipher suites is
sufficient,
when taken in combination with the well defined error conditions when
unable to negotiate a connection.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@xxxxxxxxxxxx
transcending structure.  -- The Tao of Programming   |