Re: Moving forward (fwd)

[Ned Smith <nsmith@xxxxxxxxxxxxxxxxxx>]

I'm confident there is a common middle ground. Some previous posts have
intimated that TLS had architectural insufficiencies. I haven't seen any
postings that add much more clarity. Barring more clarity I'd like to
suggest an alternat approach to mandating (or not) ciphersuites.

How about focusing only on the key exchange mechanism. This is the part of
the ciphersuite which affects which TLS messages get passed. The other
elements (symmetric/hash algs, keysize, mode etc) only affect the content.
In otherwords, choosing DES over RC4 only changes the values of computed
structures (MS, cyphertext) it doen't affect which of the optional messages
get passed.

Maybe it makes sence to say certain key exchange methods MUST be
implemented but leave the policy of cipher, keysize, mode, hash alg as
SHOULDs. This way the TLS spec wouldn't be in the position of mandating
elements of site security policy, while it would mandate key exchange
"mechanisms". (Essentially, TLS is a key exchange protocol afterall). 

(I admit to not having thought a lot about this - I'm just trying to
brainstorm a little and to get some refinement of the IESG's requirements)

Regards,
Ned


At 02:13 PM 7/25/97 -0700, Chris Newman wrote:
>On Fri, 25 Jul 1997, Christopher Allen wrote:
>> 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.
>
>Not good enough.  A proposed standard has to have both rough concensus of
>the WG and IESG approval.
>
>It actually looks like the list getting closer to agreement assuming the
>language is written in terms of "these are the mandatory-to-implement 
>cipher suites unless the profile of TLS for a specific application
>specifies otherwise."  I suggest the document editors put something like
>that in words they find acceptable.  If nobody on the WG list objects
>strongly to the results, we're done.
>
>I suspect part of the communication disconnect we're seeing is that some
>of the TLS implementors are thinking Intranet while the IESG and others
>like myself are thinking Internet.  With Intranet you're primarily
>concerned with intra-company communication and interoperability is less of
>an issue.  With the Internet you ignore the existence of companies and
>assume lots of individual computers each with custom implementations that
>have to successfully communicate with each other.  The latter paradigm has
>much stricter interoperability requirements and is what IETF standards
>describe.
>
>To try to explain where I'm coming from, think about the following
>scenario: Take 100 compliant POP+TLS server implementations and 100
>compliant POP+TLS client implementations.  Pick any pair, install it with
>"standards compliance mode" so it does only what's required by the POP+TLS
>specifications and nothing more.  Also remove all software and hardware
>not required by the standards (including proprietary gateways and
>translation layers). If any pair can exist which fails to fetch mail with
>encryption (the primary goals of POP and TLS), then the standards are
>broken.  Note that by this stringent test, most standards are broken, but
>we still have to do our best.  If we know of any problem which causes a
>failure in this scenairo, we need to fix it before moving on.  Lack of a
>mandatory cipher suite will cause a failure.
>
>		- Chris
>
>
>
>
>
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~