IETF Logo Mail Archive

Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis

Keith Moore <moore@cs.utk.edu> Thu, 14 June 2007 11:14 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HynHz-00026S-N4; Thu, 14 Jun 2007 07:14:55 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HynHx-00026E-RF for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 07:14:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HynHv-00025t-Po for discuss@apps.ietf.org; Thu, 14 Jun 2007 07:14:53 -0400
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HynHu-0003I2-In for discuss@apps.ietf.org; Thu, 14 Jun 2007 07:14:51 -0400
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 751421EE192; Thu, 14 Jun 2007 07:14:49 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv0YLJmNg1T4; Thu, 14 Jun 2007 07:13:51 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 7514F1EE152; Thu, 14 Jun 2007 07:13:42 -0400 (EDT)
Message-ID: <467122CE.2090501@cs.utk.edu>
Date: Thu, 14 Jun 2007 07:13:18 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis
References: <BA772834-227A-4C1B-9534-070C50DF05B3@mnot.net><392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><p06240871c28dd59e7371@[10.20.30.108]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6>
In-Reply-To: <031901c7ae6a$68e12360$0601a8c0@pc6>
X-Enigmail-Version: 0.95.0
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Adrien de Croy <adrien@qbik.com>, Apps Discuss <discuss@apps.ietf.org>, ietf-http-wg@w3.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

>>
>> Seems to me that the issue of securing communications and authenticating
>> or identifying parties are closely aligned, why not just have some form
>> of auth built into TLS, then we could use it for any protocol that can
>> use TLS, instead of having to implement separate auth schemes for every
>> higher protocol.
>>
>>     
> TLS can do that but it does not gel with the way in which (many) organisations
> are structured.  Those responsible for security, for security credentials and
> their maintenance, do not want to be ferreting around in the depths of a network
> stack, they prefer working at application and database level, a point that has
> already been alluded to in this thread.

how exactly does sending TLS credentials involve ferreting around in the
depths of a network stack?

v2.8.7 | Report a Bug | By Email