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

["Kyle Hamilton" <[e-mail]>]

On 1/4/07, Mark Brown <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls