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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Martin,

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.  

> The last two Online-shops where I ordered computer parts explicitly
> indicated that neither the successful completion of the "checkout",
> and not even the "autometic confirmation email" sent as a result of
> the checkout would be legally binding in any way for them to ship
> the requested product for the displayed amount and conditions.
> 
> Only an explicit confirmation Email generated in their backend
> system (usually sent within a business day) will confirm the
> contract. (I don't know whether those involve human action(s).

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.

Regarding security, you raise a good point:

> In pretty much every serious deployment the front-door of a business
> system runs on a host in the DMZ, and the only "valuable" thing
> that this possesses is a keypair suitable for online authentication
> of the server.  A business/organization would be quite stupid to
> deploy keys with digital signature capabilities in any legally
> binding sense on such a host.
... 
> TLS-based Evidence would be entirely useless in these scenarios,
> because they already have had issues when the intermediate/frontend
> systems failed (or were hacked), and the businesses don't want to
> be held responsible for that.  A very common error is a typo in
> the price of the web shop, and it did happen to companies like Dell.
> 
> It would be a pretty stupid idea to include the easiest and well
> known point of failure (and point of attack) into the creation
> of legally binding digital signatures.

"Legally binding" is out of scope, but the issue about DMZ is a good
security question.  

Using a DMZ or another kind of strong separation (for example partitions in
a MILS separation kernel) is the reason that TLS Evidence allows the PKC
used for TLS session authentication to be different from the PKC used for
signing the Evidence- structures.  However, separating out the signing
component (the TLS Evidence handler) from the TLS layer is probably overkill
for commercial applications.

Why?  Because no one can generate TLS Evidence by compromising only the
server's private keys.  TLS EvidenceResponse structures are only valid after
both TLS client and TLS server have signed them.  So for your scenario to
generate valid TLS Evidence you need the attacker to have compromised the
TLS server's authentication key and evidence key (they may be one and the
same though) and to have possession of the client's authentication key and
evidence key (they may be one and the same).  This is not very feasible
unless the attacker is the client.  

So let's say the attacker compromises the TLS server and both keys and
copies these down to his lab.  In the lab, the attacker generates a TLS
session with mutual authentication and TLS Evidence in play, dummies up a
request for a ticket that looks realistic, and dummies up a response that
also looks realistic.  Now we have a forged ticket signed by the real
server's PKC and a dummy client PKC.

The attacker knows that just about anyone could check the TLS Evidence
later.  So the attacker needs to make some hard choices.  Should the
attacker get the dummy client PKC signed by a CA?  Should the dummy client
PKC be signed by a CA that the TLS server trusts -- perhaps a CA that
charges money for its PKCs, or perhaps a CA operated by the TLS server's
organization?  Perhaps the app server shows the last 4 digits of a credit
card number used to pay for the ticket on all real receipts -- should the
attacker use a real credit card number in the app data sent in the lab?  Now
that credit card info is part of the TLS Evidence record.  Or perhaps the
app server requires the buyer to send in his/her name to be printed on the
ticket receipt -- should the attacker use a real name?  Etc.

The attacker would have to be pretty bold to use a PKC with his real name
and/or embed a real credit card number into the app data signed by TLS
Evidence.  If a credit card number was used, a suspicious third party could
check to see if the charge actually went through.  In a dispute, a third
party might ask for secondary identification -- show me the credit card,
show me your driver's license -- if forgery was suspected (the attacker did
grab both private keys from the TLS server by force...).  

On the other hand, you could buy a server certified at EAL6+ to do the TLS
and TLS Evidence for you, and that would make the foregoing discussion moot
by today's standards.  Key compromise of an EAL6+ box is supposed to be
pretty hard to do.

In any case, TLS Evidence makes no guarantees about the law / legality, or
that it prevents crime, etc.  What it does is to use cryptography to make
forgery more difficult.  This could be useful to applications.

--mark


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