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

[Martin Rex <martin.rex@xxxxxxx>]

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