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

From: "Mark Brown" <[email-masked]>
Date: Thu, 4 Jan 2007 14:27:55 -0600

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:[email-masked]]
> Sent: Thursday, January 04, 2007 1:21 PM
> To: Mark Brown
> Cc: [email-masked]; [email-masked]
> 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 [email-masked], 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Jan 2007 21:49:57 +0100 (MET)

> either the merchant or by contacting your credit card issuer.

No I am confused.

Since you just completely disclaimed the usefulness of TLS evidence
for just about every business application, what's left?

I don't see anything besides law enforcement, and I have serious
problems in making cleartext escrow plus digital signing of
the communication an IETF working group item.

-Martin

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Fri, 5 Jan 2007 18:15:23 -0500

see inserted:
----- Original Message ----- 
From: "Martin Rex" <[email-masked]>
To: "Mark Brown" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 04, 2007 3:49 PM
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

> for just about every business application, what's left?

I have more "disclaimers": at least in US and at least one big b2b exchange
said that they have a simple non-repudiation practice:
they make customers (buyers and sellers) to sign the agreement that
stipulates that whatever is the record of a transaction in the exchange
database that holds as the non-repudable record. (the name witheld due to
the NDA). So they have no need for even application level non-repudiation.
Also consumers in US have Reg A that allows them to repudiate transactions
even if a business has evidence.
-Omirjan

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Mon, 8 Jan 2007 16:44:46 -0500

see inserted:

----- Original Message ----- 
From: "Omirjan Batyrbaev" <[email-masked]>
To: <[email-masked]>; "Mark Brown" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 05, 2007 6:15 PM
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

> > > instead of what the buyer thought, (99,999.-).  So what?  In both
cases
> the

> > I don't see anything besides law enforcement,

law enforcement usage has a number of "disclaimers" too. For example, the
criminals can simply refuse to upgrade their clients to the software that
has the evidence software in it.

-Omirjan

>>and I have serious