RE: Closing on shared-key authentication

>From: 	david.brownell@Eng.Sun.COM[SMTP:david.brownell@Eng.Sun.COM]
>
>I'll have to go back and look at the comments from last
>week's proposal (ssl-talk is where I saw most of it),
>but this proposal really doesn't seem "cooked" to me.
>
>   - Internationalization issues arise.  In what character
>     set do "display_string" and "challenge" appear?  How
>     is the language which the end user knows specified?
>     
>     I don't like seeing application layer issues intrude
>     on transport layer protocols.

The "display_string" field is opaque; that is, TLS simply transports it
without examining its content.  It is entirely the next level's
responsibility to figure out what to do with it (or even if it should be
sent in the first place).  Why is this an "intrusion" into the transport
layer, any more than, say, the presence of the opaque application data
which is passed through TLS as part of its basic function?
>   
>   - Neither "rough consensus" nor (multiple instances of)
>     "working code" exists, as has been pointed out.
>     
>     Many of us don't see a technical benefit to making TLS
>     be incompatible with SSLv3 in this respect, so I doubt
>     that a realistic "consensus" on this point can exist.

Well, the real problem is that virtually *any* difference between TLS
and SSL 3.0 would make TLS incompatible with SSL 3.0, because SSL 3.0
simply lacks a mechanism for forward compatibility.  If we do nothing
else, we absolutely *must* prevent this problem from grandfathering its
way into TLS.  (The fix that's been suggested as least painful to SSL
3.0 implementers is to specify that unrecognized handshake message types
be ignored--hence our use of new handshake message types to implement
shared-key authentication.  If someone has a better way to permit
extensibility, then I'd be happy to hear about it.)
>   
>   - It's unclear just where in the handshake these new
>     messages would go.  Or are they even part of the
>     regular handshake protocol?  Do they go after the
>     "Finished" messages are exchanged, are they an
>     independent handshake, or what?

The posted document specifies where the extra messages should go.
>   
>   - Given that the amount of keying material to be built
>     is derived from the negotiated cipher spec, what's
>     the change needed in the definition of a cipher spec?
>     It needs to know it must generate CipherSpec.hash_size
>     (times two?) bytes of keying data.

In SSL 3.0 (and presumably TLS), the actual keying material is not
included in the cipher_spec, but rather as part of the general
connection state.  Implementations that don't support shared-key
authentication can, of course, ignore the extra keying material
altogether.
>   
>   - There's a new requirement, to ignore unrecognized
>     handshake messages rather than treat them as errors.
>     I prefer protocols to be fully specfied.

If it's preferable, the specification can certainly require that
implementations recognize the extra handshake messages.  Of course, the
real problem here is SSL 3.0's lack of an extensibility mechanism; see
my comments above.
>
>I could raise more questions, but the fact that there are
>this many (after this much discussion!) says to me that the
>proposal should not be deemed "cooked" enough to incorporate
>into an IETF standard.

To my mind, the problems with the proposal, as enumerated by David, cast
a worse light on SSL 3.0 than on the proposal itself.


				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com

>
>
>

Received on Tuesday, 8 October 1996 20:43:18 UTC