[Megaco] Terminology related to TLS and DTLS; RE: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"

"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Fri, 10 October 2014 19:32 UTC

Return-Path: <albrecht.schwarz@alcatel-lucent.com>
X-Original-To: megaco@ietfa.amsl.com
Delivered-To: megaco@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C4B1ACEFB; Fri, 10 Oct 2014 12:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 dYoEKLn7EeuA; Fri, 10 Oct 2014 12:32:46 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 DB21C1ACEF9; Fri, 10 Oct 2014 12:32:42 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 58B2BDBDB18B7; Fri, 10 Oct 2014 19:32:37 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s9AJWegY004917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 21:32:40 +0200
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 21:32:40 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "megaco@ietf.org" <megaco@ietf.org>, "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: Terminology related to TLS and DTLS; RE: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"
Thread-Index: Ac9DjZ+ZjmG0vyWtSwSda/q5qX0LqCg9SQKw
Date: Fri, 10 Oct 2014 19:32:40 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1AC33F0C0@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <786615F3A85DF44AA2A76164A71FE1AC1B5B78@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <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.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/megaco/9-y23U3KcUO-MHSy1pB9-lBFVTo
Cc: "3GPP_TSG_SA_WG3@LIST.ETSI.ORG" <3GPP_TSG_SA_WG3@LIST.ETSI.ORG>, "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG>
Subject: [Megaco] Terminology related to TLS and DTLS; RE: TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Media Gateway Control <megaco.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/megaco/>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2014 19:32:48 -0000

fyi,
we've developed an hierarchical terminology framework for TLS and DTLS (in context of H.248 gateways, serving the termination or interworking of (D)TLS protocol).
However, the terminology isn't gateway specific, defined in a general manner, thus applicable (and fully consistent) to IETF TLS RFCs in our understanding.

Download:
AVD-4600 H.Sup.13 (Rel. 2): Terminology related to TLS and DTLS
http://wftp3.itu.int/av-arch/avc-site/2013-2016/1411_Seo/AVD-4600.zip  

Regards,

Albrecht, Jens & Juergen

PS
The formal proceeding behind AVD-4600 may be found in:
AVD-4614 Backup-material to AVD-4600: Formal description of "TLS terminology framework"
http://wftp3.itu.int/av-arch/avc-site/2013-2016/1411_Seo/AVD-4614.zip 

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: Mittwoch, 19. März 2014 17:10
To: TLS@ietf.org
Subject: [TLS] TLS 1.3: Enhanced definitions of terms "TLS session" and "TLS connection"

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


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls