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

Keith Moore <moore@cs.utk.edu> Thu, 14 June 2007 20:42 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 1Hyw9Z-0000Mq-Qr; Thu, 14 Jun 2007 16:42:49 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hyw9X-0000Mg-RX for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:42:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw9X-0000MY-Hz for discuss@apps.ietf.org; Thu, 14 Jun 2007 16:42:47 -0400
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyw9W-00061x-BG for discuss@apps.ietf.org; Thu, 14 Jun 2007 16:42:47 -0400
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 436751EE236; Thu, 14 Jun 2007 16:42:45 -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 fb4DTV1JCw+O; Thu, 14 Jun 2007 16:41:47 -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 E3A961EE233; Thu, 14 Jun 2007 16:19:42 -0400 (EDT)
Message-ID: <4671A2C8.6050509@cs.utk.edu>
Date: Thu, 14 Jun 2007 16:19:20 -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> <467122CE.2090501@cs.utk.edu> <017001c7aea6$254a9f00$0601a8c0@pc6>
In-Reply-To: <017001c7aea6$254a9f00$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: 798b2e660f1819ae38035ac1d8d5e3ab
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

>> how exactly does sending TLS credentials involve ferreting around in the
>> depths of a network stack?
>>     
>
> It doesn't:-)  Those responsible for the creation and maintenance of security
> credentials - which I see as the major ongoing work of security - prefer to do
> at an application level, using appropriate databases, which are
> somewhat removed from the lower layers in which TLS sits.  So TLS has a
> different set of credentials or none, which is the problem that channel binding
> overcomes.
maybe what I think of as "application level" is different than how you
think of this term, but I've never heard of a client application that
uses TLS where TLS wasn't being called by the application, and where the
application wasn't in a position to supply credentials via TLS to the
server.

I'm not trying to be picky here.  Rather I think there's probably an
important principle here that needs to be teased out.

Keith