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

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

Martin,

I'm trying to engage in a constructive dialogue. I don't know everything and I doubt that you do. So can we have this discussion with a little less flame?

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'm simply curious whether this solution has a place or not. The solution itself does not have a serious security flaw. But the way it is used can, if used improperly.

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

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Martin Rex [mailto:martin.rex@xxxxxxx]
> Sent: den 5 januari 2007 10:57
> To: Stefan Santesson
> Cc: tls@xxxxxxxx
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
>
>
> Stefan Santesson wrote:
> >
> > I don't think this discussion is fair to the proposal,
> > but in a way it is what I expected to see when bringing
> > the concept of "evidence" to a TLS group.
> >
> > If we leave the concept of evidence out of scope and leave
> > it to the lawyers to worry about, is there any technical merits?
> >
> > There is one that I think we should consider.
> > If a client or a server want to ask its opponent
> > to sign a portion of data, is there any alternative
> > solutions that would work cross platforms.
>
> Of course there are, and have been in active and successful use for
> more than a year.
>
> They're at least as portable as the TLS implementation itself.
>
> >
> > PKCS#7/CMS or XML digsig is not an answer as it only provides
> > signature format, it does not deal with the request and response
> logic.
>
> You're kidding.  You wouldn't know how to implement a function in
> an application UI that requests a signed Document (PDF,CMS,XMLsig)
> from the backend?  In the HTML-world of the Internet this thing
> is called Hyperlink/URL.
>
> When Kerberos5-PKINIT was polluted ("enriched") with CMS and OCSP stuff
> you didn't seem to have a problem, and there is a proposal to ram
> Kerberos/GSS-API into TLS, so it is a total mystery to me why
> you suddenly try to make a problem out of CMS.
>
> The big advantage with this approach is that you don't need any
> additional
> APIs in order to retrieve TLS evidence from deep down, no new APIs to
> perform verification of the signature, it works perfectly fine with
> the installed base of middleware and client-software and best of
> all, you don't need thousands of case-specific custom software to
> make sense and visualize the raw network data of a TLS Evidence
> capture.
>
>
> >
> > Going higher up closer to the application requires standardization of
> > solutions based on vendor specific interpretation languages such as
> > Java or .NET.
>
> If that was anywhere as difficult as you think, then we wouldn't
> have PDFs or SWFs.
>
> Since right now, and for some considerable time to come,
> frontend/client-
> signing will still be rare and it is a total non-issue for the
> backend/server-signing.
>
>
> >
> > The balance is a delicate problem. But I'm sure that if there is a
> > solution that is technically sound from a protocol perspective,
> > then there will be a way to implemented in a sufficiently secure
> > way for many usages.
>
> TLS Evidence doesn't fit into the TLS architecture AT ALL,
> and there is an irresponsibly huge hazard that apps will use
> it all the wrong fashion and end users will be hopelessly
> confused about whether a TLS popup is about online
> authentication or a digital signature, so that a large
> number of applications will get it totally wrong.
>
> It is about a good idea as using pure liquide nitroglycerine.
>
> Responsible security engineers should stay away from this
> as far as they can.  Our standards should not only be secure,
> but also fairly safe to use.
>
> >
> > As to the security discussion earlier, a very common way to
> > eliminate the insecure DMZ is to publish the web server from
> > a secure front end firewall holding and/or controlling the TLS keys.
> > Unless you can hack that firewall you won't get to the keys or
> > the server app side of the information flow. In any case, just
> > because there is a way to implement a solution badly, does not
> > mean that there is no good way to do it.
>
> Get real.
>
> The only reason that we have DMZs is that "businesses" insist
> on running feature-bloated, bug-ridden applications on the
> public internet which will have serious vulnerabilities found
> and published on a weekly, if not daily basis for decades to come.
>
> It really doesn't matter which application vendor you pick, all
> of them are affected, just that some of them are more attractive
> targets than others, have more vulernabilities published on a
> regular basis and therefore pose a higher risk for their operators
> of successful hacks/break-ins.
>
> DMZs are used to host the machines and "frontends" of web-shops,
> as a first line of defense, and they are supposed to filter
> and pre-process requests&data before submitting it for processing
> to a backend system on the internal network which hosts the
> vital company data.  By closely monitoring the traffic within
> the DMZ and between the app/proxy in the DMZ and the backend
> system, you have significantly higher chances to notice and
> stop attackers from reaching your vital backend system.
>
> This approach works remarkably well, and it is being done
> that way for more than a decade now.
>
>
> I find it quite distracting that everytime that I show obvious
> vulnerabilities an a proposed application scenario making use
> of TLS Evidence that someone says:  Oh, that is obvious fraud--
> we don't worry about that, we can give it to the police and sue...
>
> Sorry, but that is the stupid reaction from a markedroid, definitely
> not from a security-experienced engineer.  A good design doesn't
> have such vulnerabilities.  Substituting security engineering and
>  good design with evidence collecting for law enforcement agency
> and passing on the scapegoat to them is the most stupid approach
> to security that I've ever heard in a working group of the IETF
> security area.
>
>
> -Martin

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