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

[Chris Newman <[e-mail]>]

Keith Moore wrote on 6/14/07 16:19 -0400:
>>> 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.

TLS software stacks are starting to ossify into both operating systems and 
hardware devices.  The TLS stacks are already hideously complex and I'm seeing 
increasing resistance to change in both the providers and consumers of TLS 
software.  If you've ever looked closely at GSSAPI or the CMU SASL API, adding 
a generic authentication API to a TLS software stack would _greatly_ increase 
the API complexity.  So much so that I'd personally choose to avoid using a TLS 
software stack that included such complexity.

While I have no doubt that tightly coupling authentication and the security 
layer produces a more secure system in theory, I'm also skeptical that such a 
service can achieve all the requirements of both while having enough simplicity 
to be sustainable/maintainable/secure in practice.  SSL/TLS has been around for 
years, is probably our most mature (and heavily used) security service beyond 
plaintext passwords and we're still finding deployed security holes in the 
software stacks.

The TLS channel bindings concept decouples the security layer software from the 
authentication service software so they can evolve separately.  I consider this 
such an important architecture/design improvement that it more than outweighs 
the slight impact on security from separating the two stacks (indeed as the 
separated systems are each simpler, I expect it will improve security in 
practice over a tightly-coupled design).

The major problems involved with the security layer are related to hardening of 
cryptographic algorithms and I/O stack management.  As it's a continuous 
service it has to be rock solid.  Issues with bad APIs, configuration 
complexity and whatnot can largely be hidden by higher layers as long as the 
cryptography and I/O handling are solid.  The major problems with 
authentication are centralized management and identity migration.  Again and 
again I've seen customers ignore more advanced authentication algorithms if 
they fail to achieve the management/migration requirements.  Although the 
authentication algorithms may be cool to geeks like us, they are of secondary 
importance in the real world.  The primary skill sets needed to work on a 
security layer vs. an authentication service are thus almost completely 
disjoint.  As a result I consider the architectural separation and channel 
bindings concept absolutely critical to producing a workable replacement for 
today's web-forms+passwords model.  The management/migration/branding/usability 
requirements are the non-negotiable ones, the actual authentication algorithm 
used is irrelevant absent a solution to the primary requirements.

                - Chris