Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

[Martin Rex <martin.rex@xxxxxxx>]

Dear tls fanciers,

I want to apologize for my offensive language in this discussion,
it was quite inappropriate.  I'm sorry.

My problem is, I am REALLY scared by this TLS evidence proposal, because of

(a) I consider it a very bad idea to create protocols in a way that
    digital signatures over something when the signer and the
    receipients of the signed data are not fully aware and consenting
    about every meaningful bit in the signed data and also fully
    aware and consenting about each signature operation

(b) its obvious, real and enormous potential of abuse of the proposed
    "application doesn't know, TLS stack collects evidence for third party"
    approach.

(c) I consider it an extremely bad idea to subvert the current
    TLS architecture and abuse a key pair that has been used
    in a proof-of-presense for online authentication for
    digitally signing of raw communication data.

     
(d) because it archtectually doesn't fit AT ALL into basically all of
    the existing (serious and security-conscious) SSL/TLS deployments
    that *I* know

(e) because of the many and serious security vulerabilities that will
    arise when this technologies becomes available in the installed
    base of SSL/TLS deployments


The architecture is a security disaster for many threat models that
I can think of, and if the response to this is "Oh, I don't care
about your threat models, I have my very own limited threat model
and very esoteric deployment where your concerns don't matter,
and should they do I'm confident that some lawyer can take over
and deal with the damage and probably sue, then this really
scares the shit out of me.

In the IETF, we normally try to come up with good engineering
solutions.  And if there are clear architectural problems
in not so uncommon SSL/TLS deployments integrating this
proposal, and also clear security vulerabilities for common
deployments, then an effective denial (oh, that's not the
usage scenario I'm looking for), is unlikely to get us
anywhere near a generally useful protocol extension
that integrates smoothly with existing deployments,
is safe to use and very difficult to abuse.



Stefan Santesson wrote:
> 
> I think you misunderstand my problem statements. Both user
> authentication and signing of transactions in interactive
> web services such as on-line banking has historically been
> problematic and forced users to use either external devices
> or download client plug-ins. I haven't followed this lately
> but last time I checked this was still an issue.

I do NOT consider this an "ISSUE", it is the only reasonable approach,
is less confusing to the user in that there is a huge difference
between online-authentication and digital signatures and
are much harder to abuse in that digital signatures are going
to be pushed out to users in a covert fashion.

Why does Microsoft want a tigther integration between TLS
and Kerberos authentication?  Because this is what customers
desperately want in order to do single Sign-On.  Just that
the TLS Evidence is mutually exclusive with a lot of things,
including cert-less single sign-on with Kerberos.

One generic approach to creation of digital signatures
(or two, one for the frontend and one for the backend),
that will work independent of the online authentication
scheme that is being used will be so much better for all
of us, and in particular for the average end user.


> 
> I'm simply curious whether this solution has a place or not.

TLS Evidence is the most evil protocol extension (proposal) I am aware of.

>
> The solution itself does not have a serious security flaw.

On my scorecard it has several security flaws.


>
> But the way it is used can, if used improperly.

That's an interesting way to put it.
If I get around to it, I'll put it up for the next BigBrother award.

> 
> I think we can leave the DMZ out of this. There are different
> architectures with different problems.

Really bad idea.  DMZ has significant security benefits and
is being used and necessary in many SSL/TLS deployments.
It already was a good idea 10 years ago, when you didn't
have weekly 0-day vulnerability reports.

Responsible sysadmins of large companies do not only use a DMZ
to seperate the company network from the internet, they also
have one or more internal networks seperated with a DMZ
from the company internal network.  And even without a
"full blown" DMZ, the main characteristic of a single entry point
through an SSL Accellerator or Reverse Proxy with Load-balancer
is the norm for large-scale application deployment using
web-based presentation frontends.


-Martin

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls