Re: [TLS] Comments on

Bill Frantz <frantz@pwpconsult.com> Tue, 18 February 2014 06:17 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA821A05F1 for <tls@ietfa.amsl.com>; Mon, 17 Feb 2014 22:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXcxokjkwEho for <tls@ietfa.amsl.com>; Mon, 17 Feb 2014 22:17:09 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9422E1A0609 for <tls@ietf.org>; Mon, 17 Feb 2014 22:17:09 -0800 (PST)
Received: from [174.240.0.194] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1WFdzL-0002cS-Fi; Tue, 18 Feb 2014 01:17:05 -0500
Date: Mon, 17 Feb 2014 22:17:00 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Priority: 3
In-Reply-To: <CACsn0c=Xe1Z6X0NTYQ7q6=SgGCVvQAXfFde=-aZ=xmXhr8_Qdw@mail.gmail.com>
Message-ID: <r422Ps-1075i-5AFD3810B4C14FA493B915BB14B4E0F6@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79dc15266565d7107457b38c6e7776d783350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 174.240.0.194
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kQ0iL0wGYOF2Jm9gRFj5L3g9udU
Cc: Adam Langley <agl@imperialviolet.org>, Niels Möller <nisse@lysator.liu.se>, tls@ietf.org
Subject: Re: [TLS] Comments on
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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, 18 Feb 2014 06:17:11 -0000

On 2/17/14 at 9:38 PM, watsonbladd@gmail.com (Watson Ladd) wrote:

>The application has to be ready to accept truncations on arbitrary
>subblock boundaries for this to work out.
>That's not the same as semantics indicating the entire file is fine if
>you can read from it.

However, it is a situation that any application that is reading 
files needs to be prepared to handle. Disk errors and all 
that...  Not much different from losing the network connection 
either. In fact, there is probably no way to assure the 
application that it absolutely, no fail -- ever --, will be able 
to read some data, even if the data is all in main memory.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was 
working, the
408-356-8506       | rate of systems being compromised would be 
going down,
www.pwpconsult.com | wouldn't it?" -- Marcus Ranum