- From: Jeff Williams <jwkckid1@ix.netcom.com>
- Date: Thu, 10 Oct 1996 14:54:51 -0500
- To: ietf-tls@w3.org
Tom, Please read below your comments. At 12:30 PM 10/10/96 -0700, you wrote: >Jeff Williams wrote: >> >>>- We aren't just trying to solve a problem for next quarter, we're >>> trying to generate a security standard for the Internet that will >>> stand the test of time. I don't think we should be guided by >>> short-lived customer requirements. >> >> True. Some of these customer requirnments however will be long >> term and should be reviewed with that in mind. I am an advocate >> of looking long term myself. I also believe that some of the >> precieved short term customer requirnments do need attention however, >> otherwise we will have a hard time achieving the long term goals. > >You are quite correct. However, short term customer requirements for >password authentication can be met by using existing authentication >mechanisms in existing protocols. There is no need to add a mechanism >to TLS when all existing protocols already have a password mechanims. I realize that. But my concern is not just that we may need to consider adding it to TLS for those customers whom believe in that mechanism, all be it not necessary, possibly. Again I still believe that a "Common" Protocol interface well featured would go a long ways in solving or addressing some short term problems at teh very least. Extensions to that interface for enhancments to existiing or possably new protocols, would also project a method of achieving long term desires here. Don't you think this makes some sense? > >>>- The only security reason for including password auth in TLS is that >>> it gains stronger security by having access to strong crypto in the >>> export case. I don't think we should include features this major >>> based solely on brain-damaged US export regulations that will >>> hopefully soon change. >> >> I hope you are right here, Tom. I am not so sure that those >> regulations will change all that soon. In the interum however it >> seems necessary to address password auth, for the short term. I don't >> see how this should or would inpune TLS in any really meaningfull way, >> long term. > >Even if you think we'll be limited to 40-bit for export forever, do you >really believe that any password scheme is going to provide better than >40 bits worth of security for authentication? If you can remember a >password with 40 bits of entropy then you have a better memory than I >do. No of course not. I couldn't remember much more than 10! ;) But is it really necessary to remember. I can be pluged into the login procedure. > >As to the lifting of export restrictions, the White House is already >talking about raising the limit to 56 bits, and there is legislation >pending that would lift export restrictions altogether. I feel very >strongly that an international standard should not be burdened with >major features with such substantial security implications for reasons >of local governmental policy. 56 bits is a total waste of time in my opinion. It wouldn't take much more than 3 seconds to break that! Without at least 128 bits being approved for export international companies will not support commerce for long on the net. In addition, even 128 bit in my humble opinion is a bit short of what I would like to see. With reguard to what you say reguarding local gov. policy, I am not quite clear as to what you mean here? Explain please, ok? > >-- >You should only break rules of style if you can | Tom Weinstein >coherently explain what you gain by so doing. | tomw@netscape.com > > Jeffrey A. Williams SR.Internet Network Eng. CEO., IEG., INC., Representing PDS .Ltd. Web: http://www.pds-link.com Phone: 214-793-7445 (Direct Line) Director of Network Eng. and Development IEG. INC.
Received on Thursday, 10 October 1996 16:18:32 UTC