Re: Digest mess

RT> From: Randy Turner <rturner@sharplabs.com>
RT> Subject: Re: Digest mess

RT> Speaking as someone who is using HTTP for Internet Printing, I would
RT> like to see security mechanisms removed from the core HTTP
RT> specification.

  See the latest drafts - they have been.  This does not mean that
  they should not be supported, just that they are specified separatly.

RT> If we're going to adequately address security, I would like to see it
RT> solved more robustly. Transport Layer Security (TLS) seems to address
RT> most, if not all, security requirements of most applications using
RT> HTTP.

  Digest is not and never has been designed to support all possible
  security requirements of HTTP or anything else - it is intended to
  provide an unencumbered lightweight authentication mechanism.

  As has been pointed out many times on the IPP list, there is a
  substantial segment of the market for whom authentication only is
  plenty of security service.  'Security' does not mean 'Encryption'
  (nor the other way around).

RT> There seem to be two problems to solve for HTTP using TLS; 1) We need
RT> an in-band signaling mechanism so that clients and servers can
RT> negotiate whether or not the overhead of a security encapsulation is
RT> required, and 2) We need a TLS profile that specifies unencumbered
RT> cipher suites to be used.

  (1) is beyond our current scope; Keith Moore has asked for (and, I
  expect, will get) volunteers to work on this, but we can't look
  forward to an implementable specification in the very short term.

  (2) is problematic because at the core of TLS is public key crypto,
  for which there are no unencumbered algorithms (before that
  statement starts a debate, let me qualify it - I am not interested
  in shipping a product for the purpose of contesting what someone
  else thinks is an indefensible patent claim - if you would like to
  risk your business on that sort of thing then I salute you, but I
  absolutly can not do it).

  Even if some usefull unencumbered suite can be assembled, the
  computational cost of doing _just_ authentication and integrity (the
  goal of Digest, remember) using TLS is dramatically higher than the
  Digest mechanism - MD5 is computationally _very_ inexpensive.

  Before you reject Digest as a mechanism you want to exist, I suggest
  that you do some work to really figure out the relative costs in
  technology licensing, development time, required CPU, and required
  memory in a product and run those numbers past your product
  management people - see what thier reaction is to the floor you have
  placed on product cost.

Received on Wednesday, 17 December 1997 07:06:21 UTC