Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11

Roland Zink <roland@zinks.de> Mon, 04 January 2016 16:31 UTC

Return-Path: <roland@zinks.de>
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 62B031A8A50 for <tls@ietfa.amsl.com>; Mon, 4 Jan 2016 08:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] 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 E0sAtu5PeiCj for <tls@ietfa.amsl.com>; Mon, 4 Jan 2016 08:31:55 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BD01A8A47 for <tls@ietf.org>; Mon, 4 Jan 2016 08:31:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1451925111; l=1628; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=G/Zx2yJwbsNSNBMfOPyz5Sqlznrwt3RE3A77UA14+eM=; b=kxulbYpfcJhAjNYkd2rcj6BQpjhY/DRgUkk8JKqHrzT5We8DiNG7gIQV66KeNJMhWWq IbDh/7Whzl2uEjmTMicHvu0FikEUtgHtHcG8Xj7K0FAD6Cr7LkH0ITpjbgateNRdYUuGc K5XBJOM+NesxqfObT/26inYthHDTF0fMd30=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyIm+dxs6P4z8eYGLHQraBl7TqcmA==
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2001:4dd0:ff67:0:992c:b672:6189:fcc5] ([2001:4dd0:ff67:0:992c:b672:6189:fcc5]) by smtp.strato.de (RZmta 37.15 AUTH) with ESMTPSA id v04828s04GVooy5 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Mon, 4 Jan 2016 17:31:50 +0100 (CET)
To: tls@ietf.org
References: <CACsn0cnGTqmYm0zF0C4LKxQj8oERNBhKz_CtyFCZckUgtXGKBQ@mail.gmail.com> <652841533.487342.1451923195258.JavaMail.yahoo@mail.yahoo.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <568A9E83.8050502@zinks.de>
Date: Mon, 04 Jan 2016 17:32:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <652841533.487342.1451923195258.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/pmwttQfI_ZuH6fGIdp3Ptqq7IiU>
Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 04 Jan 2016 16:31:57 -0000

TCP keep alives are handled by the TCP stack and not given to TLS or as 
Watson said invisible to TLS.

Roland

Am 04.01.2016 um 16:59 schrieb nalini.elkins@insidethestack.com:
>
> On Mon, Jan 4, 2016 at 7:45 AM,  <nalini.elkins@insidethestack.com> wrote:
>>> Hello All,
>>>
>>> Please excuse if this topic has been previously discussed.  I have a question about TCP Keep Alives.
>>>
>>> Section 5 of draft-ietf-tls-tls13-11 reads:
>>>
>>> "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol."
>>>
>>> Then continues with:
>>>
>>> "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension.  If a TLS implementation receives an unexpected record type, it MUST send an
>>> "unexpected_message" alert."
>>>
>>> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat).   I take it that this will not work going forth?
>> TCP Keep Alive is invisible to the TLS connection.
> I see. Then, is it that PACKETS without the TLS record protocol may be sent on the TLS connection, but IF the TLS Record protocol IS used, then the record types must be one of those described?
>
> Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to TLS?
>
>
>
>>   Thanks,
>>
>> Nalini Elkins
>> Inside Products, Inc.
>> www.insidethestack.com
>> (831) 659-8360
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>