Re: [TLS] Straw poll on TLS SRP status

[Martin Rex <Martin.Rex at sap.com>]

Kemp, David P. wrote:
> 
> We all know that there are communities where client certs have worked
> quite well in practice.  Based on that experience, we are at the point
> of arguing not over whether client certs should be used (they are) but
> whether smartcards should be required or software is good enough.  Try
> banging on Google's top entry for "defense online" without a cert; there
> is a huge community of users with certs who use it every day.

I'm not very familiar with the various kinds of support for crypto hardware
that is out there, or those that you're thinking of.

The one that I know (available for the OEM software that we ship)
performs only the secret key operations in hardware (on the smartcard)
because its primary function is to not reveal the private key.

Even if there were smartcards able to hold arbirarily large and complex
lists of trust anchors and able to independently build certificate
chains and perform path validations -- as long as the security critical
action is performed in regular software, that software can be trojaned
(skipping the PKI checks or ignore the results).

I see one area where an improvement might be useful (at least for those
platforms where users do not always work with full privileges, and
where we believe that there exists some level of effective privilege
seperation): have the private-key operations performed by a
privileged system service rather than entirely within the
process space of the user application, sort-of a software-smartcard.


> 
> But if password-based authentication must be used, I agree that it must
> be as tightly bound to session establishment as client certs currently
> are.  Perhaps that will be achieved in practice with "separate subsystem
> with channel bindings", perhaps not.  Cert operations are handed over to
> the PKCS-11 subsystem yet are still bound to the handshake; in principle
> a PBE subsystem and binding interface could be implemented with equal
> care.

Just that we currently don't have suitable channel bindings in
the installed base of SSL/TLS that will work transparently accross
all deployed scenarios (some of which are using seperate consecutive
but independently protected communication links).  A re-encrypting
reverse proxy (including SSL Accellerators) is probably the most
common multi-hop scenario.

But if the nature of SSL/TLS channel bindings is defined and nailed
down, then the existing deployments may be adopting means to
transfer them in multi-hop scenarios in similar fashions how they
make SSL client-cert authentication work in multi-hop scenarios,
and that work must only be done once.

-Martin

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls