[TLS] TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Wed, 19 March 2014 16:09 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.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 9BD6C1A07B9 for <tls@ietfa.amsl.com>; Wed, 19 Mar 2014 09:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 ZhDMofz8MJL6 for <tls@ietfa.amsl.com>; Wed, 19 Mar 2014 09:09:52 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECD31A07C1 for <TLS@ietf.org>; Wed, 19 Mar 2014 09:09:52 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2JG9fUI002465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <TLS@ietf.org>; Wed, 19 Mar 2014 11:09:43 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2JG9bNr031717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <TLS@ietf.org>; Wed, 19 Mar 2014 17:09:41 +0100
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.116]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 19 Mar 2014 17:09:40 +0100
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"
Thread-Index: Ac9DjZ+ZjmG0vyWtSwSda/q5qX0LqA==
Date: Wed, 19 Mar 2014 16:09:39 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC1B5B78@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6nauogQr3IGXuMHA25ntj3H8b4A
Subject: [TLS] TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"
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: Wed, 19 Mar 2014 16:09:55 -0000

Dear All,
like to raise a question related to the RFC 5246, Appendix B "Glossary":

Status: 
- connection:	
       A connection is a transport (in the OSI layering model definition) that provides a suitable type of service.  For TLS, such connections are peer-to-peer relationships.  The connections are transient.  Every connection is associated with one session.

- session:	
       A TLS session is an association between a client and a server. Sessions are created by the handshake protocol.  Sessions define a set of cryptographic security parameters that can be shared among multiple connections.  Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

Both terms are rather high-level and silent concerning a number of key characteristics.
E.g.,
What constitutes exactly a "TLS session"? Just the 1-tuple of a "session id" or the 6-tuple of {session identifier, peer certificate, compression method, cipher spec, master secret, is resumable}" (based on clause 7/RFC 5246)?

Similar, what constitues exactly a "TLS connection"? An n-tuple based on the ConnectionState on clause 6.1/RFC 5246, just a sub-set ..., the 5-tuple of IP transport connection endpoint addresses?

What exactly is the relation between a "TLS session" and its associated "TLS connection(s)"?

Resumption of a "TLS session"? What kind of "data object (configuration)" is exactly used as starting point for the "resumption procedure"?

Such kind of questions are all leading to the baseline of good terminology. The existing Glossary could and should be improved in my understanding.

Any opinions, comments from TLS expert side?
Anyone aware of similar terminology enhancements requests in the past?

Thanks,
Albrecht