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

[Martin Rex <martin.rex@xxxxxxx>]

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