Re: [TLS] Sending fatal alerts over TCP

Bodo Moeller <bmoeller@acm.org> Tue, 20 December 2011 18:32 UTC

Return-Path: <SRS0=Qyu2=7A=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33B121F84A2 for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 10:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.626
X-Spam-Level:
X-Spam-Status: No, score=-101.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZw0mVDs1onX for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 10:32:10 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id CF74321F84B4 for <tls@ietf.org>; Tue, 20 Dec 2011 10:32:09 -0800 (PST)
Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MPrBi-1RZCrv3iAE-0053DZ; Tue, 20 Dec 2011 19:32:06 +0100
Received: by qadz3 with SMTP id z3so4377945qad.10 for <tls@ietf.org>; Tue, 20 Dec 2011 10:32:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.98.8 with SMTP id o8mr4268402qan.79.1324405924738; Tue, 20 Dec 2011 10:32:04 -0800 (PST)
Received: by 10.224.19.196 with HTTP; Tue, 20 Dec 2011 10:32:04 -0800 (PST)
In-Reply-To: <4EF0D014.1050907@extendedsubset.com>
References: <82ehvzidu4.fsf@mid.bfk.de> <4EF0D014.1050907@extendedsubset.com>
Date: Tue, 20 Dec 2011 19:32:04 +0100
Message-ID: <CADMpkc+4LVwLw7Ft9xOkrv9-+_0HpuvOsO3Vkp8=mR3RGbt8kQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=20cf3074d9a6aeb69c04b48a4898
X-Provags-ID: V02:K0:/M1vpbR871vVLM/jWWQuO1PTDPMFLdgYGtssxsTc2Ba jCA+lBqgVuh0ynG3K/QRhptU6X6xh9+rJWd5dYrVjt9c+A+4g4 lPqG1QFZR56f/eeqs7Kajr0RaTS9TZ6XEgtAx7CHVve1a5OkHE py4MYRk7Juk/To07I6OWYC5+Nqri0QeXZ+s1u0xJvt7OJ1r5YG usrrn0PqtonCf+5hUw8x2OPyr8Ud+W2/cPkowZGwUgmGSp3CaL HmtqM6RuG3zuelnFpYhNCreZ8aPNoW5asGliaFg0juCGSADLSo 92ECTv5+R29ZaAn0l9+ztplfZUPIxVNC8QjXXSbjkBA7goExf2 7VLTRYd5mW3hPOUu3xDyws83GfKXazDjI+gSRcEqsFMpJJoDzQ j/YE21zH6u5Y1RUYfAcU53EKexBr+PVeoMCatnVVde+0hRMWS9 uI7qN
Subject: Re: [TLS] Sending fatal alerts over TCP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Dec 2011 18:32:39 -0000

On Tue, Dec 20, 2011 at 7:12 PM, Marsh Ray <marsh@extendedsubset.com> wrote:


>   X shuts down the connection
>>   Y sends data to X
>>   X receives from Y, sends RST to signal data loss to Y
>>
>

>  This would seem to be against the spirit of
> http://tools.ietf.org/html/rfc793 (section 3.5. Closing a Connection)
> which says "Users must keep reading connections they close for sending
> until the TCP says no more data."
>

Note that RFC 1122 section 4.2.2.13 specifies that

            A host MAY implement a "half-duplex" TCP close sequence, so
            that an application that has called CLOSE cannot continue to
            read data from the connection.  If such a host issues a
            CLOSE call while received data is still pending in TCP, or
            if new data is received after CLOSE is called, its TCP
            SHOULD send a RST to show that data was lost.


I'm guessing that on typical systems, this behavior for close() *does*
depend on the SO_LINGER parameters, though.

Bodo