[TLS] New Liaison Statement, "Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]"

Liaison Statement Management Tool <lsmt@ietf.org> Mon, 02 February 2015 18:33 UTC

Return-Path: <lsmt@ietf.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8E1A885A; Mon, 2 Feb 2015 10:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id X9N0QsUnN6iw; Mon, 2 Feb 2015 10:33:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5921A1A20; Mon, 2 Feb 2015 10:33:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool <lsmt@ietf.org>
To: Rosa De Vivero <rosa.angelesleondev@itu.int>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150202183354.30380.30799.idtracker@ietfa.amsl.com>
Date: Mon, 02 Feb 2015 10:33:54 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cQ01sb-9MouDmZocY5wVz2lpxOs>
X-Mailman-Approved-At: Mon, 02 Feb 2015 13:58:52 -0800
Cc: Christian Groves <christian.groves@nteczone.com>, Scott mansfield <scott.mansfield@ericsson.com>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, Transport Layer Security Discussion List <tls@ietf.org>
Subject: [TLS] New Liaison Statement, "Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 02 Feb 2015 18:33:59 -0000

Title: Response to LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4]
Submission Date: 2015-02-02
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1379/

From: Transport Layer Security (Sean Turner <tls-chairs@tools.iet.org>)
To: ITU-T Q3/16 (Rosa De Vivero <rosa.angelesleondev@itu.int>)
Cc: Joseph Salowey <joe@salowey.net>,Stephen Farrell <stephen.farrell@cs.tcd.ie>,Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>,Transport Layer Security Discussion List <tls@ietf.org>,Scott mansfield <scott.mansfield@ericsson.com>
Response Contact: Christian Groves <christian.groves@nteczone.com>
Technical Contact: 
Purpose: In response
Referenced liaison: LS on TLS and DTLS terminology [to 3GPPA SA3, IETF WG TLS, 3GPP CT4] (http://datatracker.ietf.org/liaison/1363/)
Body: Thanks for your questions about (D)TLS.  What follows is a response to your questions; questions proceeded by Q# and answers by A#.  If you have additional question please let us know.


[What is] the distinction between (D)TLS session and (D)TLS connection (which implies a definition for each term, beyond the available descriptions / glossary from RFC side)


A TLS session is shared cryptographic state established by a full TLS handshake between two peers.  The session’s cryptographic state is used to establish the cryptographic key material for a TLS connection.  A TLS connection is a transport relationship established between two peers that contains the cryptographic state to cryptographically protect data sent and received on the connection established through a full or abbreviated (session resumption) TLS handshake.  A TLS session may span one or more TLS connections.  Every TLS connection is associated with one TLS session.  If session resumption (abbreviated handshake) is not used then the TLS session and TLS connection will essentially be the same.  A TLS session is identified by a Session ID in the client and server hellos.  A TLS connection is usually identified by a host addresses and port numbers.


The DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something in addition?


The DTLS association is the same as a DTLS connection


The TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS connection level) does this procedure occur?


The TLS resumption procedure: what is the definition and relation to TLS renegotiation?

A3 and A4:

Resumption refers to the use of the state from an existing TLS session to establish a new TLS connection using an abbreviated handshake.  During resumption the cryptographic parameters (algorithms etc.) remain the same.  TLS renegotiation is the process of executing a new TLS handshake to establish new cryptographic parameters for a TLS connection (effectively a new TLS connection using the same host addresses and ports as the previous one). If the handshake is a full handshake then both a new session and a new connection are established and the renegotiated session may have different parameters.

Please note that session resumption and renegotiation are optional features; though TLS 1.2 recommended support for renegotiation; renegotiation was also updated by RFC 5746.  Please note that TLS 1.3 is currently under development and these features are being reviewed.

No document has been attached