- From: Dan Simon <dansimon@microsoft.com>
- Date: Thu, 10 Oct 1996 10:56:40 -0700
- To: Don Schmidt <donsch@microsoft.com>, "'elgamal@netscape.com'" <elgamal@netscape.com>
- Cc: Barb Fox <bfox@microsoft.com>, "'ietf-tls@w3.org'" <ietf-tls@w3.org>, "'treese@OpenMarket.com'" <treese@OpenMarket.com>, "'david.brownell@Eng.Sun.COM'" <david.brownell@Eng.Sun.COM>
The problem of forward compatibility in SSL 3.0 goes beyond the particular issue of password authentication. In fact, the password authentication feature can be included in TLS with complete SSL 3.0 compatibility, as long as TLS hello messages have a new, higher version number, and TLS servers are required to fall back to SSL 3.0 (without client auth.) when communicating with a pure SSL 3.0 client. (A similar solution works for a number of other proposed TLS enhancements; the issue of SSL 3.0 backward compatibility in TLS is therefore something of a red herring.) The broader question is whether we want to maintain such strict SSL 3.0 backward compatibility as to freeze the TLS client hello forever as an SSL 3.0 client hello. There are a number of potentially attractive changes (such as "quick" key exchange, for instance) which would ultimately require changes to the client hello message, but because of SSL 3.0's lack of an extensibility mechanism, any of these would automatically preclude complete SSL 3.0 backward compatibility. In offline discussions, it has been mentioned that a relatively painless way to break this compatibility is to allow new handshake message types in TLS, and assume that SSL 3.0 implementations simply ignore them. That way, additions to the client hello can be in the form of appended handshake messages. I therefore propose that we: 1) Select a version number for TLS, so that proposals for additional features can be explicitly made compatible with SSL 3.0; and 2) Consider proposals for incorporating extensibility into the TLS client hello message (starting, presumably, with the proposal to have TLS require that unrecognized handshake messages be ignored without error). Note that these items involve the handshake protocol only, and do not interfere with efforts (which I support) to split the protocol into independent "handshake/key management" and "record" components. Daniel Simon Cryptographer, Microsoft Corp. (dansimon@microsoft.com) >---------- >From: elgamal@netscape.com[SMTP:elgamal@netscape.com] >Sent: Thursday, October 10, 1996 8:43 AM >To: Don Schmidt >Cc: Dan Simon; Barb Fox; 'ietf-tls@w3.org'; 'treese@OpenMarket.com'; >'david.brownell@Eng.Sun.COM' >Subject: Re: Closing on shared-key authentication > >I did not cast a vore against forward compatibility in general at all. >Actually the current shared secret proposal does not solve that either, >in the sense that to incorporate kerberos or some other auth mechanism >we need to add yet other messages. > >I was not under the impression that we were after designing forward >compatibilty in the TLS protocol. If that is the case, we could do the >split document thing and work on an extensible handshake. > >Taher > > > >Don Schmidt wrote: >> >> I am delighted to see the last two postings from Taher and Barb getting >> back to the point. That is the utility of a TLS standard. If after all >> we design something that is secure but does not meet customer >> requirements -- and so is not widely adopted -- then why bother? >> >> Many (if not most) of the arguments against incorporating shared-secret >> auth in TLS (the transport vs app layer arguments) could apply equally >> to PK-based auth. >> >> Many of the obvious interoperability benefits of incorporating a >> standard PK-based auth into TLS could equally apply to shared-secret >> auth. >> >> The point here is not whether PK-based auth is more secure than >> shared-secret auth, or whether it provides non-repudiation, or ... >> >> The relevant facts here are: >> - This working group is chartered to develop a transport layer security >> standard. >> >> - Rough consensus has decreed that SSL3 is the best starting point. >> >> - Everyone recognizes the value of the robust key exchange, auth, >> integrity and encryption capabilities that derive from PK technology. >> >> - Real consumers of products to be built according to the TLS standard >> have stated that the infrastructure, key management and portability >> issues associated with PK technology are acceptable on the server side. >> But they also have clearly stated their need to support millions of >> end-users who currently use passwords and are not ready to switch >> wholesale to private keys and certs. >> >> - Real customers want the benefits of a single standard for Transport >> layer security but with their choice of auth technology. In fact, they >> will most likely have to support both shared-secret auth and PK-based >> auth in parallel for some time, probably a couple of years at least. >> >> - If the TLS standard were to support both auth mechanisms then it would >> be possible to provide implementations which prevent applications from >> having to know or care what kind of credentials were used to >> authenticate the end-user. Applications could be written to a single >> interface and could be upgraded just once to support legacy client auth >> (shared-secret) and still migrate to admittedly superior client auth >> (PK-based). >> >> Why is there such resistance to this line of reasoning? If rough >> concensus holds that the TLS standard cannot support both shared-secret >> and PK-based auth, then fine, take them both out and put them both in >> the application layer. But give me one standard so that applications >> developers, customers and end-users don't have to be hamstrung by the >> differences in authentication technology. >> >> Don Schmidt >> Program Manager >> Microsoft Corp >> >> >---------- >> >From: Barb Fox >> >Sent: Wednesday, October 09, 1996 5:01 PM >> >To: Dan Simon; 'elgamal@netscape.com' >> >Cc: 'ietf-tls@w3.org'; 'treese@OpenMarket.com'; >>'david.brownell@Eng.Sun.COM' >> >Subject: RE: Closing on shared-key authentication >> > >> >>Taher: >> >> >> >>I just have to jump in here to clarify a couple of things. >> >> >> >>Yes, password authentication is a customer requirement. Many companies >>tell >> >>us that they want a migration path from passwords to certificate-based >> >>systems within the TLS protocol standard. This has been the sole reason >>we >> >>have been pushing so hard for password authentication...customer need. >>The >> >>business side of this argument has already been comprehensively presented >>by >> >>John Macko (Compuserve) in an earlier posting (7/22) so I don't want to >> >>start >> >>that chain again here. >> >> >> >>But Dan's comment about forward compatibilty in SSL has nothing to do >>with >> >>passwords per se. Fact: there is no generic extensibility mechanism in >>SSL3 >> >- and that's something we need to acknowledge and fix as soon as we can. >> >> The goal of this working group, after all, should be to create an >> >>architecturally-sound, extensible standard. I admit that this will cause >>us >> >>all some pain as we find ourselves having to change our fielded >> >implementations to prepare for future advances in the protocol. But if >> >>we bite the bullet and design the protocol correctly now, it shouldn't be >> >>such a big deal as we go incrementally forward. >> > >> >>Barb >> >> >> >>---------- >> >>From: elgamal@netscape.com[SMTP:elgamal@netscape.com] >> >>Sent: Wednesday, October 09, 1996 8:49 AM >> >>To: Dan Simon >> >>Cc: 'ietf-tls@w3.org'; 'treese@OpenMarket.com'; >> >>'david.brownell@Eng.Sun.COM' >> >>Subject: Re: Closing on shared-key authentication >> >> >> >>Dan, >> >> >> >>You bring an interesting point. In the design of SSL3.0, we did not >> >>expect that the protocol would have to support weaker authentication >> >>techniques, actually going backwards if you think about it. The idea of >> >>SSL3.0 was not to support everything that may exist or everything anyone >> >>can think of. So, you cannot really accuse SSL of not being forward >> >>compatible because it assumes a good authentication method rather than >> >>duplicate old ones that everyone has already implemented in any >> >>interesting application protocol. The only reason for me to entertain >> >>this password thing is that a customer thinks it is useful, not really >> >>because it adds anything to the protocol, on the contrary, it makes it >> >>less attractive since the level of authentication is not defined. >> >> >> >>Taher >> >> >> >> >> >>Dan Simon wrote: >> >>> >> >>> >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 >> >>> >> >>> > >> >>> > >> >>> > >> >> >> >>-- >> >>Taher Elgamal elgamal@netscape.com >> >>Chief Scientist, Netscape Communications >> >>(T) 415 937 2898, (F) 415 428 4054 >> >> >> >> >> > > >-- >Taher Elgamal elgamal@netscape.com >Chief Scientist, Netscape Communications >(T) 415 937 2898, (F) 415 428 4054 > >
Received on Thursday, 10 October 1996 18:28:53 UTC