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

[Martin Rex <martin.rex@xxxxxxx>]

Mark Brown wrote:
> 
> Personally, I can see how it could be to the seller's advantage to not print
> receipts that customers could use -- that way, they can avoid being held
> accountable.  

You get it wrong.  It is about businesses not wanting binding digital
signatures on data that has been produced by the most untrusted
equipment on their premises -- the machines in the DMZ.

It will cost you big bucks to have any such signatures created
on a EAL6+ certified piece of hardware, but that doesn't really
fix the real problem -- that the signatures will get applied
to transactions processed by a fancy web-shop (frontend) running
on LAMP or IIS and with pricing information that a vendor
must consider about as accurate as on printed advertisement.

The possibility to steal signature keys is just one aspect of the
security problems around the TLS Evidence proposal.

The larger problem is about the data that gets signed and the
interpretation of that data.  An attacker doesn't need to
compromise/steal the keys if he can get data of his choice
signed, e.g. by by subverting the vendors web shop application
or by subverting the entire client software (e.g. a trojan using
cross-site scripting of some sort).


> 
> However, some buyers might want a solid receipt when making purchases.  Not
> a receipt like the email you mention, since it really is not a sure thing
> that the email will ever get to you or contain accurate information.  If
> used, TLS Evidence could do a better job at receipts than this email system
> you mention.

PKCS#7 / CMS, signed PDF, XMLsig, whathave you are all readily available.

See https://www.global-esign.com/
for verification of legally binding digital signatures by a
government accredited CA on CMS and signed PDFs (as for the
Invoices of the German Internet Service Provider I mentioned).


SSL/TLS client certificates are still rare these days, and using
them for (legally binding) digital signatures would be a pretty
dumb idea security-wise.

One conceivable approach would be to use for secure client-side digital
signatures would be an EAL6+ certified USB-gadget with its own TFT-display,
keypad and crypto modules/key storage that can display (pure text-based)
contractual data and allow the user to apply individual digital signatures
only on small, known and trusted pieces of information as displayed on
the screen of the gadget.  That should be doable in the OLPC price range,
and be fairly secure even for home users running MSIE on Microsoft Windows on
a regular PC.


TLS Evidence is a flawed approach, because what is signed there is
a client software from software vendor A, usually completely outside
of control of an end-user B, talking to an (application) server software
for vendor X supplied by software vendor Y, and usually neither
user B nor vendor X are aware what information is really exchanged
(and signed) at the network level and how much of their (conscious)
actions has what kind of impact on what gets sent and signed.
It would hardly help them to know, since it largely depends on
what software vendors A and Y ship and whether their software
or machine has been trojaned/XSSd/hacked.


-Martin

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