Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Tue, 11 May 2010 09:53:49 -0400

Are you planning to use full 160 bits of SHA-1 output? If not - you realize that possibility of collision on truncated output is higher?

Regards,
Uri

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Sent: Tue May 11 09:39:50 2010
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

Nicolas Williams wrote:
> 
> Stefan Santesson wrote:
> > 
> > What if a collision occurs?
> > 
> > That is pretty deterministic too. The server and the client may then agree
> > on a cached value by mistake. They will then go ahead and try to complete
> > the handshake with different opinions on a cached security critical value,
> > such as disagreeing about the server certificate chain. This will inevitably
> > lead to a handshake failure.
> 
> That's what I thought.
> 
> > Upon a failed cached handshake, the client and server tries a new handshake
> > without caching, updates it's cache and moves on with life.
> 
> Well...  Many applications might not.  Can the handshake be retried
> transparently to the application?  Or will the application have to
> close() its socket and re-connect()?

Re-thinking this scenario, I do not think that is a workable approach.

The reason why I originally asked for using a (sha-1) hash value over the
replaced data instead of a simple, server-assigned identifier,
was robustness.  Going through a handshake failure is _NOT_ an option.
I wanted to avoid the cache of the server and client to get out-of-sync,
and the use of a sha-1 hash value over the real data instead of that
data should be sufficiently robust so that the server will send the
real data in case the clients cached value differs from what the
server would normally send.

It is generally impossible to recover from a TLS handshake failure.
It normally requires closure of the existing connection and opening
of a new connection because it is completely unspecified how to
recover from a TLS handshake failure on a connection (and how to
clear the network pipe from unprocessed data from the previous handshake).

If a client-side proxy traversal is involved, a full app-level proxy
handshake is required.  If proxy traversal requires an OTP authentication,
it will be completely impossible without user interaction.

-Martin
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 11 May 2010 13:11:22 -0500 (GMT-05:00)

David and all,

  Well said and fully agreed!  But as you likely know
too many are not yet ready for prime time.

-----Original Message-----
>From: "Kemp, David P." <[email-masked]>
>Sent: May 11, 2010 1:03 PM
>To: [email-masked]
>This sounds like a general problem unrelated to caching.
>
>If a non-browser app cannot recover from failures, what happens when a
>bit error gets through multiple layers of detection and correction, or a
>DSL connection dies and restarts?   "Stuff happens" all the time, and
>humans know how to hit the "retry" button.  An unattended application
>that doesn't know how to recover from unexplained errors is not ready
>for prime time.
>
>Dave
> 
>
>-----Original Message-----
>From: Nicolas Williams
>
>That's what I expect as well, that handshake failure is not transparent
>to _all_ applications, and that any retry logic will have to be in the
>application.  That makes this protocol a bit problematic -- failures
>will be rare, no doubt, so rare that we might not care, but when they
>happen the application won't know that the failure is not permanent.
>For browsers that may not be a problem (the user will just reload); for
>non-browser apps (and scripts running in the browser!) this could be a
>problem.
>

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827