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

"tom.petch" <cfinss@dial.pipex.com> Mon, 18 June 2007 09:52 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 1I0Du1-0002xN-Gd; Mon, 18 Jun 2007 05:52:05 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I0Du0-0002xE-8D for discuss-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:52:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dtz-0002x5-Pg for discuss@apps.ietf.org; Mon, 18 Jun 2007 05:52:03 -0400
Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Dtz-0006MD-B3 for discuss@apps.ietf.org; Mon, 18 Jun 2007 05:52:03 -0400
Received: from pc6 (1Cust210.tnt9.lnd4.gbr.da.uu.net [62.188.138.210]) by astro.systems.pipex.net (Postfix) with SMTP id 825BEE0000D0; Mon, 18 Jun 2007 10:51:58 +0100 (BST)
Message-ID: <01fe01c7b185$52f800a0$0601a8c0@pc6>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Keith Moore" <moore@cs.utk.edu>
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> <4671A2C8.6050509@cs.utk.edu>
Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis
Date: Mon, 18 Jun 2007 10:44:58 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
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
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
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

----- Original Message -----
From: "Keith Moore" <moore@cs.utk.edu>
To: "tom.petch" <cfinss@dial.pipex.com>
Cc: "Adrien de Croy" <adrien@qbik.com>om>; "Apps Discuss" <discuss@apps.ietf.org>rg>;
<ietf-http-wg@w3.org>
Sent: Thursday, June 14, 2007 10:19 PM
Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis

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

It is good to be picky; it ensures I am thinking clearly (or not as the case may
be).

I think the problem arises at the receiving end, where TLS needs to validate
credentials and where, as in the more secure organisations that I see, the
credentials may be stored in a proprietary database (Active Directory, Domain
Controller and other manufacturers' equivalents).  I do not see the interface
from TLS to this store so that whatever the incoming credentials need to be
compared with can be obtained by TLS.  Hence TLS gets its own set.

Also, while I see no issue with the passing around of a certificate between
application and TLS, I do see an exposure doing this with other forms of
authentication eg passwords. (Certificates, like IPv6, are a good solution to a
widespread problem that the world at large irritatingly refuses to adopt:-(.

With channel bindings, TLS passes on a secure identifier of the channel which
the application can then use to check that there is no Man In The Middle, so
there are no such concerns there.

Tom Petch

> Keith
>