Re: Closing on shared-key authentication

> At this point, I propose that we adopt the proposed
> modifications for the TLS draft. As always, I am happy
> to hear comments either on the list or in direct mail.

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.
   
   - 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.
   
   - 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?
   
   - 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.
   
   - There's a new requirement, to ignore unrecognized
     handshake messages rather than treat them as errors.
     I prefer protocols to be fully specfied.

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.

- David Brownell
  JavaSoft

Received on Monday, 7 October 1996 19:09:23 UTC