Simple SSL/TLS - Some Questions

Anne & Lynn Wheeler lynn at garlic.com
Tue Oct 7 23:53:32 EDT 2003


At 08:38 PM 10/7/2003 -0400, Ian Grigg wrote:

>You are not being fair, Lynn, you are hijacking
>the name of TLS, in order to promote a protocol
>to protect credit cards.
>
>What you described was practically nothing to do
>with TLS/SSL...
>
>Such a protocol would be quite useful no doubt,
>but it has little to do with TLS' design goal of
>being a full service channel security product.

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

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.

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.

As to usefulness .... I wasn't really trying to claim it would be useful 
.... just that it would meet the business requirements of its primary use.

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.

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

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

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.

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?

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


--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  

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



More information about the cryptography mailing list