RE: [TLS] Review of draft-santesson-tls-gssapi-00
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TLS] Review of draft-santesson-tls-gssapi-00



Eric,

I hear what you say. I still wander why that is a problem, more than philosophically.
I said IF, we can take security out of the picture (if we can solve that issue so whatever GSS-API come up with, security is preserved), what is then the problem?

Also provided that there are ways for the state machine to bail out and detect the end of the exchange, then what is the actual problem with that.

To time consuming?
To bandwidth consuming?
To insecure anyway?
just not pretty enough?
Or something else..

It doesn't seem very radical to me to have a protocol design which allows an arbitrary number or roundtrips for a sub process as long as the main process can bail out/timeout gracefully. It wouldn't be the first time in protocol design.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: EKR [mailto:ekr at networkresonance.com]
> Sent: den 9 mars 2007 16:22
> To: Stefan Santesson
> Cc: martin.rex at sap.com; tls at ietf.org
> Subject: Re: [TLS] Review of draft-santesson-tls-gssapi-00
>
> Stefan Santesson <stefans at microsoft.com> writes:
> > If the TLS state machine still have control over the security level
> of the encryption key, would it still be a problem that several
> roundtrips is required for the GSS exchange?
>
> Yes.
>
>
> > If so, why is this a problem, except from an emotional purity
> perspective.
>
> I'm not sure how to explain it any better than I have already. TLS
> has a state machine with a given number of round trips. You're
> proposing to change it into a state machine with an *arbitrary*
> numbr of round trips determined not inside TLS but rather coupled
> with the GSS state machine. That's a radical change and strikes
> me as extremely hard to analyze.
>
> -Ekr

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.