Re: on mandatory ciphers

[Ned Smith <nsmith@xxxxxxxxxxxxxxxxxx>]

Win,
The following excerpt from Jeff Williams' reply to Chris Allen's suggestion
to just mandate a ciphersuite appeared to be unsatisfactory. Does RFC 1958
somehow fix the intimated "architecture problems" in TLS?
Thanks,
Ned Smith
--------------------------------------------------------------------------
> 
> Thus, in order to move past this process SNAFU, I'd like to see that the
> IESG officially tell the TLS working group "you must put in MUST
> ciphersuites in the TLS spec". This request should be put in writing and
> appear in the next IESG minutes (as the previous "remanding" of the TLS
> document was apparently not official as there is nothing about TLS in the
> previous IESG minutes.)

  NO NO NO!  This is not going to solve anything here.  This is passing
the buck in a sense.  Best thing to do is fix the archtecture problem.
> 
> Given that official remandment by the IESG, we (the editors) will proceed
> with putting the MUST ciphersuites into the draft, and hopefully the draft
> can finally go RFC as a Proposed Standard by Munich.

  I am strongly against this approach.  DOes not solve the underlying
problem
at all.  It mearly puts it in a political mode, and therefore weakens
what TLS is all about in my mind.
-------------------------------------------------------------------------


At 01:47 AM 7/28/97 -0400, Win Treese wrote:
>Thanks to everyone for a vigorous discussion on the question of
>mandatory ciphers.
>
>I've been thinking a lot about how we should proceed. RFC 1958, 
>"Architectural Principles of the Internet", says with respect to protocols
>providing authentication and confidentiality:
>
>  6.4 In choosing algorithms, the algorithm should be one which is
>   widely regarded as strong enough to serve the purpose. Among
>   alternatives all of which are strong enough, preference should be
>   given to algorithms which have stood the test of time and which are
>   not unnecessarily inefficient.
>
>   6.5 To ensure interoperation between endpoints making use of security
>   services, one algorithm (or suite of algorithms) should be mandated
>   to ensure the ability to negotiate a secure context between
>   implementations. Without this, implementations might otherwise not
>   have an algorithm in common and not be able to communicate securely.
>
>While RFC 1958 is not a standard, I think we can assume it reflects the
>desires of the IAB.
>
>Therefore, I believe we should go forward with requiring the suites
>TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and its anonymous
>variation to be implemented in the absence of an application
>profile standard that specifies otherwise.
>
>Speaking for myself, I do not believe such a requirement seriously
>compromises the security of the protocol or applications that use it.
>In the RFC as well as comments on this mailing list, it seems clear
>that both the IAB and IESG understand the implications of making
>such mandates, and further discussion here is unlikely to have
>much effect.
>
>It has been suggested that mandating a cipher suite such
>as TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA will cause
>problems in the future if/when the suite is deemed
>insufficiently secure. While it may be necessary to revisit
>the standards track for such a change, we can reasonably expect
>the process to be expedited.
>
>Win Treese
>treese@xxxxxxxxxxxxxx
>
>
>
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~