RE: Closing on shared-key authentication

> >   - 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.

The name of the field, at the least, strongly "suggests" that it be
displayed to users.  Display prompts and challenges are a common part
of many password-based user interfaces; the OTP (S/KEY) IETF work is
one example.  (Why wouldn't a TLS scheme build on that work?)


>	  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?

Seems to me that it's either application data, in which case it's
insignificant with respect to security and should be sent as normal
"application_data" records, or it's security data which needs to
be fully specified lest interoperability islands be created.

So for example some folk have said that PKI shouldn't necessarily
be part of TLS, any more than a password scheme.  But the PKI is
relatively well specified (X.509; RSA, D-H, or DSS public keys)
and the password schemes are not interoperably specified yet.

Plus, there's an overgeneralization:  it's not clear to me how I'd
be able to use the Kerberos V5 shared key system in an interoperable
way.  There's no "scheme ID" assigned by the IANA to indicate that
the display_string/challenge data is used (how?) by Kerberos vs. by
a Compuserve or Microsoft proprietary authentication protocol.



> >   - 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.

I don't buy this.  There are mechanisms whereby an "SSL 3.1" can be
wire compatible with "SSL 3.0".  But they're tightly constrained,
to minimize interoperability problems.  (And, as Tom Weinstein pointed
out, to enable a complete security analysis.)

Also, compatibility is an orthogonal issue to authentication (and
encryption) strength.  I'm not sure it'd be good to have the IETF
make changes via TLS that reduce the strength now found in SSLv3,
or to adopt a mechanism that's not scalable to the current size of
the Internet.  [ Repeating points others have made on this list,
since I agree and think they bear repeating! ]



> >   - 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.

I just noticed some text there.  It's not as complete as I'd need
if I were to implement this in my SSLv3 code.  Do these go before or
after ServerHelloDone?  What about the case of rejoining a session?
Where does SharedKeyVerify go?


> 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.

I don't follow this any more than your comment about lack of
support for controlled protocol evolution.

- Dave

Received on Thursday, 10 October 1996 16:29:38 UTC