Harald,
We have been following the TLS activities for some time and have also held
discussions with individual members of the WG. We were happy to use the TLS
functionality as documented up to their last draft but one, but in the
final version that was passed by the IESG they suddenly introduced some new
mandatory stuff, for which we have so far seen little or no rationale or
explanation.
Just now I am only interested to get a recommendation, from whoever
consider themselves qualified, about a "politically correct" combination of
TLS security features that provides the same functionality as SSL3. Is this
concrete enough?
Carl-Uno
At 01:19 PM 12/9/97 PST, Harald.T.Alvestrand at uninett.no wrote:
>Carl-Uno,
>>you say:
>> If the security people are going to dictate in every detail what we
>> can or cannot do, then I think it is their responsibility to make sure
>> that they participate in our WGs to give advice us advice in the
>> context of our needs and discussions, rather than come down and
>> criticize what we have done every time we think we have found an
>> acceptable solution.
>>I would say that the foot is definitely in the other shoe:
>If you see that protocol development is being done which will
>impact your product, it is definitely in your interest to make
>sure that the people doing that development know your requirements.
>>It is 100% obvious to you that when you consider using TLS, the
>TLS group is an interesting forum for you.
>It is not at all obvious to the TLS group that there is anything
>going on in Internet printing that impacts requirements for TLS.
>That group too is an open forum; the reason you are not a member is
>because you have chosen not to be.
>Most of the people working on TLS are there because they need TLS in
>*other* projects; their own requirements are obvious to them, yours
>are not.
>And remember: this is not something they do for a hobby; anything
>we ask them to do above what they already do usually comes straight
>out of their spare time.
>>The security requirements are really, really simple:
>- THINK about what security your application needs, and provide that
>- No plaintext passwords
>The requirements that apply to ALL protocols, in ALL aspects are:
>- Enough requirements to ensure interoperability
>- Avoid use of IPR-tainted technology whenever reasonable.
>The last two are NOT security requirements, it's just that the
>security area, thanks to RSA, has one of the nastiest examples of this
>being a problem.
>>BTW, I consulted with the security AD about ciphersuites in TLS; he
>was quite surprised that anyone would consider using TLS without
>security, since this adds quite a bit of overhead over raw TCP.
>Ciphersuites are "numbered items", but the intent of the TLS group
>is that it should be simple to add new ones; the reason for using
>suites rather than feature combinations is that some combinations
>of features have non-obvious but serious security flaws.
>If you want a ciphersuite with different properties than the existing
>set, take this up with the TLS group. ietf-tls at consensus.com; use the
>-request convention to subscribe.
>> Harald A
>>Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com