- From: Tom Weinstein <tomw@netscape.com>
- Date: Thu, 10 Oct 1996 10:27:41 -0700
- To: Don Schmidt <donsch@microsoft.com>
- CC: Dan Simon <dansimon@microsoft.com>, "'elgamal@netscape.com'" <elgamal@netscape.com>, 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>
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 ... [ ... snip ... ] - Password authentication weakens TLS. - The first time someone cracks a password used in TLS authentication, it will erode public confidence in the security of TLS. - 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. - 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. -- You should only break rules of style if you can | Tom Weinstein coherently explain what you gain by so doing. | tomw@netscape.com
Received on Thursday, 10 October 1996 13:34:03 UTC