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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Martin,

Isn't this attack possible with today's web sales?  I mean, once you give
your credit card to anyone, can't they ring you out at any price they want?
You don't need a website or TLS to do this attack.  You can do this on the
phone or via mail order.

So in the case of TLS Evidence, you both have a record of (1,499,999.-)
instead of what the buyer thought, (99,999.-).  So what?  In both cases the
buyer cancels the order.  You don't need TLS Evidence to cancel...with
either the merchant or by contacting your credit card issuer.

In both cases the buyer might want to go back to the website and get a
screen capture, showing how the merchant is practicing fraud...

This is really a legal issue with a merchant who is intending to defraud,
and it would be pretty easy for anyone to verify.  While hiding prices with
GIFs is a deceptive practice that's probably illegal, I want to focus on
protocol issues.

--mark

> -----Original Message-----
> From: Martin Rex [mailto:martin.rex@xxxxxxx]
> Sent: Thursday, January 04, 2007 1:21 PM
> To: Mark Brown
> Cc: martin.rex@xxxxxxx; 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