credit card threat model

Wed Oct 8 01:10:31 EDT 2003

Anne & Lynn Wheeler wrote:

> what i said was that it was specifying a simplified SSL/TLS based on the
> business requirements for the primary use of SSL/TLS .... as opposed to a
> simplified SSL/TLS based on the existing technical specifications and
> existing implementations.

I totally agree that the business requirements
for protecting credit cards have scant
relationship to the security model of SSL/TLS!

> I don't say it was technical TLS .... I claimed it met the business
> requirements of the primary use of SSL/TLS.
> 
> I didn't preclude that there could simplified SSL/TLS based on existing
> technical specifications as opposed to implementation based on business
> requirements for the primary use.
> 
> I thot I was very fair to distinguish between the business requirements use
> of SSL/TLS as opposed to technical specifications for SSL/TLS.

I think the key here is that SSL/TLS is a channel
security protocol.  But, to harken back to its days
of origin, where Netscape asked for "something to
protect credit cards," is going to confuse the
issue for a lot of people.

In preference, if we want something to protect
credit cards, then the threat models should be
established, and the protocol should be created.

Yes, SSL/TLS protects credit cards a little bit
in one part of their flight, but SSL/TLS is much
bigger and grander than that small part.  It's
fair to say, I think, that it's whole security
model plays little attention to credit cards, it's
oriented to creating a good channel over which
any developer/implementor can pass *any* data.

Hence, for example, the emphasis on replay
prevention - which is at a higher layer in a
financial protocol, and was AFAIK in place in
credit cards since whenever.  But if one is
doing a channel security product, it has to
be there, as the overlaying application won't
consider it.

> There are lots of really great implementations in this world .... many of
> which have absolutely no relationship at all with a good business reason to
> exist.
> 
> The real observation was that in the early deployments of SSL .... it was
> thot it would be used for something entirely different ... and therefor had
> a bunch of stuff that would meet those business requirements. However, we
> come to find out that it was actually being used for something quite a bit
> different with different business requirements.

This history of how the business requirements
led to the SSL model are possibly closed to us
at this point...  I wasn't there, and I'm a
bit scared to ask :)

> So a possible conjecture is that if there had been better foreknowledge as
> to how SSL was going to be actually be used .... one might conjecture that
> it would have looked more like something I suggest (since that is a better
> match to the business requirements) ... as opposed to matching some
> business requirements for which it turned out not to be used.

My own view - in conjecture - is that it comes
back to that old chestnut, what's your threat
model.  It would appear that this was one missing
phase in the early development of SSL.  Or, if
it was asked, it certainly wasn't validated, it
was predicted only.

But, in terms of useful posture today, 9 years
down the track, I personally think it is time to
give up the ghost and not ever mention credit
cards again.  Others will & do differ ...
but I don't think it is possible nor helpful to
mix and match the credit card mission and the
SSL result as if they are strongly related.

> I've repeatedly claimed that the credit card number in flight has never
> been the major threat/vulnerability .... the major threat (even before the
> internet) has always been the harvesting of the merchant files with
> hundreds, thousands, tens of thousands, even millions of numbers .... all
> neatly arranged.

Yep.  This was obvious in 94.  In fact it was
obvious in 84 - the Internet has always been a
very safe place as far as eavesdroppers go, it
ranks up there with telcos and well above
physical mail as far as reliability and privacy
goes.

Yes, of course, eavesdropping is possible, and
of course there have been many incidents.  But,
in terms of the amount of traffic, the risk is
miniscule, and probably well below the credit
card companies' real threshholds.

And, even in the presence of widespread delivery
of credit card numbers in the clear, it's easy
to show that the prime threat is and was and will
always be the hacking into some easy Linux box
and scarfing up the millions from the database.

Why they didn't see that in '94 I don't know.

> The issue that we were asked to do in the X9A10 working group was to
> preserve the integrity of the financial infrastructure for all electronic
> retail payments.  A major problem is that in the existing infrastructure,
> the account number is effectively a shared-secret and therefor has to be
> hidden. Given that there is a dozen of business processes that require it
> to be in the clear and potentially millions of locations .... there is no
> practical way of addressing integrity of such a shared-secret ((you could
> burry the earth to the depth of a couple miles with cryptography .... and
> it still wouldn't alleviate the threat).

Absolutely right!  No amount of crypto was
going to help that.

> It turns out that once the account number is no longer a shared-secret ....
> then it is no longer necessary to hide it in order to preserve the
> integrity of the financial infrastructure. At that point, a primary
> existing use of SSL/TLS goes away completely.

I couldn't agree more.

> I wasn't really to hijack the protocol .... however, if you wanted to
> simplify something based on the business requirements of its use ... then
> one might consider simplifying based on the business requirements of its
> use (even if it became somewhat different). My strong preference (by
> several orders of magnitude) is to not do anything to contribute to delays
> of eliminating account numbers as shared-secrets (that would include not
> contributing to an extreme KISS TLS other than a hypothetical mental
> exercise related to business justification as a reason for doing something)..

Well, I don't think you can use the name for
such a drastic change.  Not unless you can get
people to agree, of course, that the name really
relates to the business requirements as much as
it does to the channel security mission.

> I would prefer the primary justification for SSL/TLS to totally
> disappear  There then might remain some other uses that could benefit from
> SSL/TLS .... and they might not have a need for simplification at all.

Certainly, if we could get back to the basics
and identify what TLS is good for and intended
for, a lot of difficulties go away.  But we
can only do that by simplifying and challenging
the assumptions.  Hence, my claim that SSL/TLS
is no longer sensibly related to the credit
card business requirement, notwithstanding that
it is often used and enforced in that mission.

> Frequently when simplification is done to something .... you throw away
> stuff that isn't needed (at least for the targeted business purpose). The
> issue in extreme KISS TLS .... at what point has it become so simple that
> it can no longer be TLS  ... aka what is the minimal simple set of things
> needed for something to still be TLS?

I agree - that's why I suggest self-signed certs
as being the starting point.  I used to think
there was a role for Anon-DH, but TLS has
deprecated it, and in truth, it does make TLS
a lot simpler to think about - it's a cert-
based channel security product, no ifs, no
buts.

Then, the whole nature of the CA architecture
should be separated out, and become some sort
of adjunct.  As I mentioned before, good
protocols come in two parts, and the second
part starts with "trust this key 100%."

How you get your signed cert is a completely
separate problem.  It needs to be untangled
out and placed into a separate problem box.

> simple result of the x9a10 working group to preserve the integrity of the
> financial infrastructure for all electronic retail payments .... and
> eliminate account numbers as shared-secrets
> http://www.garlic.com/~lynn/index.html#x959

Right.  But, that looks more like a financial
protocol to protect financial messages such
as transactions.  Somewhat different to a TLS-
like channel security protocol.

Here's one test of a good financial protocol -
how well does it work without any encryption at all?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com