W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Digest mess

From: Randy Turner <rturner@sharplabs.com>
Date: Wed, 17 Dec 1997 07:22:09 -0800
Message-Id: <3497EE21.B5785E7A@sharplabs.com>
To: Scott Lawrence <lawrence@agranat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4991
Please see my comments below...


Scott Lawrence wrote:
> 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.

Ok, I will take a gander at the latest draft.
> 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
>   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).

I know the rationale for including a lightweight
auth capability for HTTP, but I think the
original rationale for including digest within HTTP
no longer exists.

> 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.

I don't reject the notion of "digest", I just don't think
we should solve the security problem <n> different times.
If you support any other protocol (other than HTTP),
then you're faced with potentially solving the
security problem for every protocol. Therefore, I don't
think the code space, development time, and required
memory is an issue. In fact, I think it is one of the
disadvantages of including security in HTTP.

Support for extensions to the available ciphersuites
and options for TLS have been included in the latest
draft. If their is a less CPU-intensive way to do
security, then we could define a new ciphersuite for

My argument is for proper layering, I only want to
include security capabilities once in my products,
and then write profiles for all applications that
use it.

Received on Wednesday, 17 December 1997 07:30:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC