W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

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

From: tom.petch <cfinss@dial.pipex.com>
Date: Mon, 18 Jun 2007 09:52:23 +0000
Message-ID: <01fe01c7b185$52f800a0$0601a8c0@pc6>
To: "Keith Moore" <moore@cs.utk.edu>
Cc: "Adrien de Croy" <adrien@qbik.com>, "Apps Discuss" <discuss@apps.ietf.org>, <ietf-http-wg@w3.org>

----- Original Message -----
From: "Keith Moore" <moore@cs.utk.edu>
To: "tom.petch" <cfinss@dial.pipex.com>
Cc: "Adrien de Croy" <adrien@qbik.com>; "Apps Discuss" <discuss@apps.ietf.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
> > credentials - which I see as the major ongoing work of security - prefer to
> > 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
> > 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

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
Received on Monday, 18 June 2007 11:23:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC