[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 1/4/07, Mark Brown <mark@xxxxxxxxxxxxxxxxxxxx> wrote:


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.


Isn't the entire point of an attack to harm the attacked?  Motives
differ for attacks.  The motives for attacks help describe/define what
attack is going to be carried out, and how.

As an example, let's look at the "disgruntled employee" concept.
Sysadmin, disgruntled, has possession of the traffic and
signature-evidence keys, as he's responsible for making sure they get
into the correct place and are used in the correct manner.

Owner or CFO or whathaveyou overlook this during employment/contract
termination.  (Which is ASTOUNDINGLY easy to do.)

Bingo, you suddenly have an attack against your business's legal existence.


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.


Should the attacker put an alternate server up, make it look like the
real thing, be authenticable as it... and let others connect to it
without realization that it's fake?


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...).


Or, be bold enough to let others do it.  Every one of the transactions
is individually actionable, and that can cripple a business with legal
fees.


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.


...except by people who have access regardless.


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.


This is not something that can be solved at the network layer.  It's
an application issue, and needs to be dealt with as such.

-Kyle H

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