IETF Logo Mail Archive

Re: [TLS] Comments on

Alfredo Pironti <alfredo@pironti.eu> Tue, 18 February 2014 10:15 UTC

Return-Path: <alfredo@pironti.eu>
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 CF5151A0625 for <tls@ietfa.amsl.com>; Tue, 18 Feb 2014 02:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 trY8M0b0Ees0 for <tls@ietfa.amsl.com>; Tue, 18 Feb 2014 02:15:28 -0800 (PST)
Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E72F91A062C for <tls@ietf.org>; Tue, 18 Feb 2014 02:15:27 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id g12so19099290oah.3 for <tls@ietf.org>; Tue, 18 Feb 2014 02:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ry73kzWr/bDFVjkTVUcEeGBSzsj4EnQpuvqgHJvqYSg=; b=T/RNiP5P6blToNBGTNkcuaJAkQE1g3L6AHsr0Qchcg9Ku0rGG6J0tOYgq1JvHZ1I7P Ec6mYVpwO6yBUtC0kKBXf+tXcfVa0R9MeT7rXoV35tPa99VwESLgmKL+3RgwoHcjRtPC mvjBADKBzSou2uXrqrbbAy33+fK6hcfDpTTvw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ry73kzWr/bDFVjkTVUcEeGBSzsj4EnQpuvqgHJvqYSg=; b=M8IZZoO5ykUahoBCkhj/v7NdH55+ovCuhiKJLb/liYQY7KDc2WvQV8l8m19i9Bh4iQ ra2TQp2bH6b1O5Dpf1has86MPZc5RVfouFU+DxqOYxmpBNUsxJdJU0dakqmXJ9qFflbl qbLY9Asusmj/Kllm476x1eNLz2rdsq+Jb+U3B9taqyQUboN3IXO8U6PHyRuekXpmYDKv Zq/uYEiYuJVu8S2k4OWzkTv+pjWiDcXUO7haUXsBSGeg4AdY1+tIyFNrqbXEWS5JZ7Wx OoYVeTukdMkk73jKbbixgXJmS1dv/jAM0F4dwIVaDV7SAxroaw3aI81ukfQiDhsFVCF0 9Xqg==
X-Gm-Message-State: ALoCoQmiTVpPK9I56DVwKlqmiduLc8OkrW1ronQF2yebEUhxy+1muTkz5rgX6ePy44iKrOAmzjOZ
MIME-Version: 1.0
X-Received: by 10.182.40.37 with SMTP id u5mr10750697obk.41.1392718524908; Tue, 18 Feb 2014 02:15:24 -0800 (PST)
Received: by 10.76.10.102 with HTTP; Tue, 18 Feb 2014 02:15:24 -0800 (PST)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <r422Ps-1075i-5AFD3810B4C14FA493B915BB14B4E0F6@Williams-MacBook-Pro.local>
References: <CACsn0c=Xe1Z6X0NTYQ7q6=SgGCVvQAXfFde=-aZ=xmXhr8_Qdw@mail.gmail.com> <r422Ps-1075i-5AFD3810B4C14FA493B915BB14B4E0F6@Williams-MacBook-Pro.local>
Date: Tue, 18 Feb 2014 11:15:24 +0100
Message-ID: <CALR0uiLN3AT_CQA1_GptJyUXzQFKvt8xfWRrqy8MfQL=dsQbbQ@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: Bill Frantz <frantz@pwpconsult.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gXqrBpwI853pDQo081tMCfhPYJo
Cc: Adam Langley <agl@imperialviolet.org>, Niels Möller <nisse@lysator.liu.se>, "tls@ietf.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 10:15:30 -0000

On Tue, Feb 18, 2014 at 7:17 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
> 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.

TLS is indeed designed to distinguish between "fatal" closure and
"graceful" closure. A "fatal" closure (fatal alert or network
disruption) ensures that a *prefix* of the data sent by the peer are
received; by comparison, "graceful" closure via full-duplex
close_notify ensures that *all* data are received as sent by the peer.
Even the standard socket and I/O functions make this distinction
(although there's no integrity check there).

Cheers,
Alfredo

>
> 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
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email