W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: Password Authentication

From: Eric Murray <ericm@lne.com>
Date: Mon, 29 Apr 1996 20:45:29 -0700 (PDT)
Message-Id: <199604300345.UAA04015@slack.lne.com>
To: bsy@cs.ucsd.edu
Cc: dpkemp@missi.ncsc.mil, ietf-tls@w3.org
Bennet Yee writes:
> I agree with most of your points about passwords.  However, the scenario
> that you draw about extensions would imply that we should think about
> mechanisms by which extensions to TLS may be made cleanly -- reserve some
> record type numbers that are vendor-specific, and mandate that the rest
> be not used except as officially sanctioned blah blah blah when/if TLS
> gets revised.  If we don't do this, then we risk creating compatibility
> problems in the future.

While I agree that an extension mechanisim might be useful, I think
there's more utility in keeping the standard simple to understand
and implement.  An extension mechanisim that allowed vendor-specific
extensions would probably require yet another negotiation, if you don't
want to repeat the HTML problem of conflicting vendor-added
features- i.e. "do I write my TLS to talk to Microscape's TLS
extentions, or Netsoft's?").  Adding another negotiation would increase
the complexity of the TLS standard.   Look at the RFCs, it's the simple
standards that have been successful and widely deployed, while there are
many super-flexible but complicated standards that have few implementations.

I think it would be better to create one simple TLS standard, then add on
additional standards or IANA registration schemes for things like
password-exchamge protocols, additional CipherSuites, support
for pre-encrypted data, etc. rather than trying to do everything now.

Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF
Received on Monday, 29 April 1996 23:46:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC