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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 11 May 2010 18:04 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3CC3A6BF1 for <tls@core3.amsl.com>; Tue, 11 May 2010 11:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.184
X-Spam-Level:
X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFYYPuH6gPn8 for <tls@core3.amsl.com>; Tue, 11 May 2010 11:04:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 250CD3A6A83 for <tls@ietf.org>; Tue, 11 May 2010 11:03:59 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 11 May 2010 14:03:39 -0400
Message-ID: <201005111803.o4BI3fhO006065@stingray.missi.ncsc.mil>
In-Reply-To: <20100511152153.GF9429@oracle.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
Thread-Index: AcrxHeCpHAifkDuWTNmdRxbEEJ5xxgAFKfvQ
References: <20100510221531.GC9429@oracle.com><201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp> <20100511152153.GF9429@oracle.com>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <tls@ietf.org>
X-OriginalArrivalTime: 11 May 2010 18:04:53.0718 (UTC) FILETIME=[75029F60:01CAF134]
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 18:04:04 -0000

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.