IETF Logo Mail Archive

Re: [TLS] Comments on

nisse@lysator.liu.se (Niels Möller ) Tue, 18 February 2014 12:56 UTC

Return-Path: <nisse@lysator.liu.se>
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 A35BA1A062F for <tls@ietfa.amsl.com>; Tue, 18 Feb 2014 04:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level:
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=no
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 61wm5PA1VUnb for <tls@ietfa.amsl.com>; Tue, 18 Feb 2014 04:56:54 -0800 (PST)
Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) by ietfa.amsl.com (Postfix) with ESMTP id 4812E1A047A for <tls@ietf.org>; Tue, 18 Feb 2014 04:56:52 -0800 (PST)
Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s1ICukr6023507; Tue, 18 Feb 2014 13:56:46 +0100 (MET)
Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s1ICufkq023491; Tue, 18 Feb 2014 13:56:41 +0100 (MET)
X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f
From: nisse@lysator.liu.se
To: Bill Frantz <frantz@pwpconsult.com>
References: <r422Ps-1075i-5AFD3810B4C14FA493B915BB14B4E0F6@Williams-MacBook-Pro.local>
Date: Tue, 18 Feb 2014 13:56:41 +0100
In-Reply-To: <r422Ps-1075i-5AFD3810B4C14FA493B915BB14B4E0F6@Williams-MacBook-Pro.local> (Bill Frantz's message of "Mon, 17 Feb 2014 22:17:00 -0800")
Message-ID: <nnlhx8inp2.fsf@bacon.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/95G_Nh1S8cNnDci4alldKPULoOw
Cc: Adam Langley <agl@imperialviolet.org>, 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 12:56:56 -0000

Bill Frantz <frantz@pwpconsult.com> writes:

> However, it is a situation that any application that is reading files
> needs to be prepared to handle. Disk errors and all that...

I think there's a difference between on one hand, truncation due to
random failures of your own, reasonably trusted, hardware. And on the
other hand, truncation caused the enemy attacking the communication
channel for some evil purpose.

If we really want to make progress with this discussion, I guess we must
also distinguish between file types where appending data doesn't change
the meaning of earlier data (e.g, a typical log file), and file types
where appending data can change the meaning radically (e.g., consider a
document format where you can add data at the end of the file which adds
a mark "this document is fake" on top of every page when the file is
displayed or printed).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

v2.23.0 | Report a Bug | By Email