Stefan Santesson wrote:
The problem is that it is very hard to engage into a discussion
unless the objections are substantiated.
I can repeat one specific objection (made by several people already):
*all* current TLS key exchange mechanisms use exactly the same state
machine, i.e. the message exchange shown in Fig. 1 of RFC 2246, while
this proposal doesn't.
This would be quite radical change to TLS. For example, the base
TLS spec assumes this state machine is always used, so either we
need to change it to accommodate GSS-API, or the GSS-API document
has to effectively overrule the base spec in many places.
(I also believe that implementation could be easier if the state
machine is not changed, but that's probably a secondary concern.)
<snip>
Structurally, the problem with your proposal that has been pointed
out to me is that many use of TLS requires authentication have to be
established before the finished message, or it will be useless. This
aspect needs to be analyzed to determined whether completing
authentication before the finished message is an absolute
requirement for a solution to be meaningful.
Could you explain why you think it will be useless?
We certainly have to complete the authentication (including GSS-API)
before we let application data through. In my proposal, that would
happen after the channel binding messages (not immediately after the
finished messages).
