Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Consensus Call: FNV vs SHA1)

["Kemp, David P." <[e-mail]>]

The security analysis should focus on the bizarre Finished message
calculation rather than on the hash algorithm.  The essence of caching
is that cached data has the same effect as transmitted data, only faster
:-).  Section 4 violates that assumption:

   "The handshake protocol will proceed using the cached data as if it
   was provided in the handshake protocol. The Finished message will
   however be calculated over the actual data exchanged in the handshake
   protocol."

If the Finished message is not calculated as if the data were actually
transmitted, then it cannot ensure the integrity of that data.  Strike
the second sentence and the problem goes away.  The transmitter has to
perform Finished calculations on the original datastream, then
post-process it to substitute hashes where possible.  The receiver first
has to expand hashes into data, and then perform handshake operations
including Finished calculations.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Marsh Ray
Sent: Tuesday, May 11, 2010 2:28 PM
To: Simon Josefsson
Cc: [e-mail]
Subject: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Consensus Call: FNV
vs SHA1)
Importance: Low

On 5/11/2010 2:59 AM, Simon Josefsson wrote:
> 
> I'm thinking about two scenarios:
> 
>  1) the undetectable modification of the list of acceptable CA names
>     cause the client to select and use an unintended certificate.
> 
>  2) where multiple server certificates can be used to successfully
>     establish the key.  That can happen if two certificates use the
same
>     public key.  Once connected, the client will not know the server
by
>     the same identity (certificate) as the server believe the client
>     used.

Frankly, this scares the hell out of me.

I admit now that part of why I supported the simple 'hashtable' function
was to ensure that this aspect got thoroughly analyzed.

> This is not an problem in the sense that an attacker gains some
benefit
> (for 1 the client chose to proceed with the certificate

Hmm, this could enable an attacker to influence the client to choose a
client cert using different information than the server thought he sent,
and in a way which doesn't break the Finished hashes?

Let's say I have separate "administrator" and "normal user" client
certs, both recognized by a server. Could mitm trick me into authing
with the admin cert even if the server app didn't intend to ask for it?

Note MS IIS has a feature for client-cert-to-user mapping, so
theoretically that could end up running code with different actual user
permissions.

> and for 2 the
> attacker needs to know the private key of the server): instead I'm
> pointing at a semantic problem because, with the extension, the
> historically true invariant that the client, after handshake, will
know
> which certificate the server used, does not hold strongly.
> 
> This doesn't necessarily have to affect the document in any way, but
it
> is an interesting property.

Historically, it has turned out to be notoriously difficult to put
limits on the effects of a violated security guarantee. We may not be so
familiar with all the dependencies and assumptions made in the original
analysis that we can run through them backwards.

I recommend we walk through the security analysis on this again from
scratch. This time with extra focus on an attacker who can trivially
craft collisions.

Also, we should look into how this might interact with running multiple
servers on the same IP address (and same stack) using SNI. Sometimes
things that are secure in isolation do not produce a secure system when
composed.

- Marsh
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls