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

[Stefan Santesson <stefans@xxxxxxxxxxxxx>]

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.

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.
Going higher up closer to the application requires standardization of solutions based on vendor specific interpretation languages such as Java or .NET.

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.

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.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Martin Rex [mailto:martin.rex@xxxxxxx]
> Sent: den 4 januari 2007 11:21
> To: Mark Brown
> Cc: tls@xxxxxxxx
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00
>
> Mark Brown wrote:
> >
> > I think you're concerned about the HTTP GET side of my illustration,
> whereas
> > TLS Evidence here would be concerned about the POST.  I'm Ok to
> assume HTTP
> > is the app as you do:
> >
> > > Browsers traditionally use up to 4 independent connections to
> retrieve
> > > parts of what composes a Web page as seen by the user, and that
> results
> > > in several parallel independent TLS-protected communcation
> channels.
> >
> > I also agree with you that what is "seen by the user" may be the
> assembly of
> > multi connections' GETs within the browser (etc.).  But TLS Evidence
> doesn't
> > worry about that; what is "seen by the user" is simply out of scope.
>
> OUCH. OUCH. OUCH.
>
>
> >
> > TLS Evidence only creates a factual record of what sent and received
> > if and only if both parties digitally sign the same hash values
> > (hashes over the sent and received data).
> >
> > The POST is the target for TLS Evidence in this illustration.  And
> instead
> > of generating a lot of useless evidence like "user fetched another
> JPEG"
> > (app designer's choice here; I'm just making a suggestion), it would
> be more
> > efficient to only capture TLS Evidence over something like the last
> step of
> > a "checkout" sequence.
>
> This is a totally flawed and insane approach!
>
> But on the other hand, it makes an interesting business model:
> As a Vendor, I can create (textual pages) with an order containing
> the real price that I want to get signed (1,499,999.-) and I use
> gifs to overlay this price in the form displayed to the user with
> the background colour, so that the user sees (99,999.-).
>
> Now in your model, the TLS Evidence is produce over the full amount,
> while the information that the user saw, and what he intended to sign,
> was a MUCH smaller amount.
>
> Unfortunately, even if the user did make a screen-cap -- the screen
> cap is unsigned, the gifs overlaying the three leading characters
> of the full price are not part of the TLS Evidence, but the full
> amount is part of the TLS Evidence.
>
>
> Now if the TLS Evidence proposal leads to so many seriously flawed
> "application solutions" from people discussing with the security geeks
> on tls@xxxxxxxx, how much worse will be the outcome of applications
> using TLS Evidence designed by the masses of security-unconscious
> application writers out there?
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls

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